RFCOMM
Matthias Ringwald
I'm glad to announce that RFCOMM is now officially part of BTstack.
So what does this mean?
in the example folder, there are two RFCOMM examples: rfcomm-cat to connect to a remote RFCOMM port and listen for data, and rfcomm-echo, which sets up an SDP record for an SPP serial port and waits for incoming RFCOMM connections.
The API for RFCOMM is similar to the one for L2CAP. See include/hci_cmds.h with explanation in src/hci_cmds.h (I've pasted it at the end, too...)
Some notes:
* As BTstack API is rather minimal, in some cases, the HCI handle for an RFCOMM channel is required, e.g. to set up a new link key. Because of this, I plan to add this handle to the RFCOMM_EVENT_OPEN_CHANNEL_COMPLETE event. The current code in SVN matches the latest BTstack-0.3-50x release in Cydia. I'll release the next update of BTstack when Celeste 1.0 is ready (to not break Celeste 0.9 yet).
* The RFCOMM engine provides flow control information via the RFCOMM_EVENT_CREDITS event. Please don't send more RFCOMM packets than you've got from BTstack.
* To set up an RFCOMM service for incoming connections, you use the rfcomm_register_service command. As BTstack must handle multiple clients, you have to specify a "registration id" instead of an actual RFCOMM service ID. In the RFCOMM_EVENT_SERVICE_REGISTERED, BTstack returns the assigned service ID which then can be used. See example/rfcomm-cat.c for an example on this
I just realized that the on-demand assignment (last note) will require another device to query SDP each time. Also this works fine for OBEX, it fails for other uses, so this will need some more thought. The problem is: "how can RFCOMM channels get assigned to independent entities without creating a collision?". The most obvious approach would probably be to add a "register RFCOMM channel for life" and/or have BTdaemon keep track of all assigned RFCOMM channels...
Anyway, please have a look at the current version and get started with the new RFCOMM!
Best
Matthias
------- API ------
/// COMMANDS
// create rfcomm channel: @param bd_addr(48), channel (8)
const hci_cmd_t rfcomm_create_channel = {
OPCODE(OGF_BTSTACK, RFCOMM_CREATE_CHANNEL), "B1"
};
// disconnect rfcomm disconnect, @param rfcomm_cid(8), reason(8)
const hci_cmd_t rfcomm_disconnect = {
OPCODE(OGF_BTSTACK, RFCOMM_DISCONNECT), "21"
};
// register rfcomm service: @param registration id(16), mtu (16)
const hci_cmd_t rfcomm_register_service = {
OPCODE(OGF_BTSTACK, RFCOMM_REGISTER_SERVICE), "22"
};
// unregister rfcomm service, @param service_channel(16)
const hci_cmd_t rfcomm_unregister_service = {
OPCODE(OGF_BTSTACK, RFCOMM_UNREGISTER_SERVICE), "2"
};
// accept connection @param bd_addr(48), rfcomm_cid (16)
const hci_cmd_t rfcomm_accept_connection = {
OPCODE(OGF_BTSTACK, RFCOMM_ACCEPT_CONNECTION), "2"
// @param source cid (16)
};
// decline rfcomm disconnect,@param bd_addr(48), rfcomm cid (16), reason(8)
const hci_cmd_t rfcomm_decline_connection = {
OPCODE(OGF_BTSTACK, RFCOMM_DECLINE_CONNECTION), "21"
// @param source cid (16), reason(8)
};
// RFCOMM EVENTS
// The current BTstack-0.3-50x in Cydia uses
// data: event(8), len(8), status (8), address (48), server channel(8), rfcomm_cid(16), max frame size(16)
// The SVN version and the next update will use
// data: event(8), len(8), status (8), address (48), handle (16), server channel(8), rfcomm_cid(16), max frame size(16)
// status: 0 = OK
#define RFCOMM_EVENT_OPEN_CHANNEL_COMPLETE 0x80
// data: event(8), len(8), channelID(8)
// status: 0 = OK
#define RFCOMM_EVENT_CHANNEL_CLOSED 0x81
// data: event (8), len(8), address(48), channel (8), rfcomm_cid (16)
#define RFCOMM_EVENT_INCOMING_CONNECTION 0x82
// data: event (8), len(8), rfcommid (16), ...
#define RFCOMM_EVENT_REMOTE_LINE_STATUS 0x83
// data: event(8), len(8), local_cid(16), credits(8)
#define RFCOMM_EVENT_CREDITS 0x84
// data: event(8), len(8), status (8), registration id(16), rfcomm server channel id (8)
#define RFCOMM_EVENT_SERVICE_REGISTERED 0x85
Matthias Ringwald
short note on the RFCOMM channel assignment problem: I've decided to add a "get persistent channel nr for service with name" in BTdaemon and change the register RFCOMM service back to directly accepting a channel nr - which provides a way to handle channel numbers on a full OS, while simplifying the API for embedded systems (as you can just pick your RFCOMM channels directly). More on that after it got implemented.
best
Matthias
Begin forwarded message:
Casainho
>
> short note on the RFCOMM
RFCOMM is the same as Serial port over bluetooth? Is btstack ready to
implement Serial por over bluetooth for cheap and simple embedded
systems as Arduino/AVR?
mungewell
I spotted a couple of minor issues, but will dig into in detail later.
1). rfcomm-echo should make the bluetooth device browsable (can't
detect it to start with).
2). You've set a name of 'SPP ECHO', but then limited this to only the
first 3 characters.
Bluez is detecting this as a 'DUN' port, rather than a 'Serial Port'.
This might be something to do with the SDP record.
Simon,
Matthias Ringwald
good point. I spent about 10 minutes preparing & testing rfcomm-echo... :)
You're right about the incorrect service name len, but why isn't it "browsable"? I tried once on the Mac: pairing, service discovery, setup virtual serial port, test with minicom. worked fine.
best
matthias
> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To post to this group, send email to btsta...@googlegroups.com.
> To unsubscribe from this group, send email to btstack-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/btstack-dev?hl=en.
>
mungewell
On May 1, 2:01 pm, Matthias Ringwald <matthias.ringw...@gmail.com>
wrote:
--
#if 1
// Make discoverable
bt_send_cmd(&hci_write_local_name, "BTSTACK");
sleep(1);
bt_send_cmd(&btstack_set_discoverable, 1);
sleep(1);
#endif
run_loop_execute();
--
Matthias Ringwald
no problem. I didn't forget that one though (but maybe in the first commit) ... -> http://code.google.com/p/btstack/source/browse/trunk/example/rfcomm-echo.c#168
Best,
Matthias
frankb
On 1 Mai, 14:07, Matthias Ringwald <matthias.ringw...@gmail.com>
wrote:
Matthias Ringwald
On 02.05.2011, at 16:14, frankb wrote:
> Is the BTstack-0.3-50x releae already available in Cydia?
ah. my version numbers got mixed up. The latest version in Cydia is 0.3-434 (http://apt.thebigboss.org/onepackage.php?bundleid=ch.ringwald.btstack&db=) and I was actually referring to that one instead. So replace 50x with 434 in my mail. There won't be a 50x in Cydia ever as the btstack.org SVN revisions are > 1000 or so.
Best
Matthias
Matthias Ringwald
Here's the follow-up on the RFCOMM channel assignment for services... I've reworked the API for service registration to use the actual server channel (1-30) in the rfcomm_register_service but added the new rfcomm_persistent_channel_for_service command which uses an identifier. For quick tests, the channel #1 can be used.
The mapping from service name to rfcomm channel is currently done by the remote_device_db - not very obvious, but it made sense to combine this functionality as both use persisten date, I just need to rename the remove_device_db into e.g. preferences or so.
If you already started with RFCOMM, please look at the changes for the RFCOMM examples. If not, please be aware that the current SVN version isn't compatible with the one in Cydia (for now - working on Celeste update).
Best
TreadMiller
current one for a while and I'm a little confused at what I need to do
to get to the point where I am receiving "RFCOMM_DATA_PACKET"
packet_type messages.
I get a bunch of HCI_EVENT_PACKET that aren't being handled for 0x0e,
0x66, 0x0f, 0x61, 0x03, 0x1b, 0x13, 0x74 and finally a 0x81.
Searching for these in the source I see a definition for 0x74 in L2CAP
(L2CAP_EVENT_CREDITS) but not HCI_EVENT_PACKET.
I see 0x81 in RFCOMM events (RFCOMM_EVENT_CHANNEL_CLOSED) but again
not in HCI_EVENT_PACKET.
What should be my next steps using rfcomm-cat as a base example to get
to RFCOMM_DATA_PACKET events?
I'm trying the code out on an iPhone 3GS.
Do I need to be running the latest BTdaemon instead of the one from
Cydia?
Any help would be great!
Thanks!
On May 3, 5:21 pm, Matthias Ringwald <matthias.ringw...@gmail.com>
wrote:
>
> The mapping from service name to rfcomm channel is currently done by the remote_device_db - not very obvious, but it made sense to combine this functionality as both use persisten date, I just need to rename the remove_device_db into e.g. preferences or so.
>
> If you already started with RFCOMM, please look at the changes for the RFCOMM examples. If not, please be aware that the current SVN version isn't compatible with the one in Cydia (for now - working on Celeste update).
>
> Best
> Matthias
>
> Begin forwarded message:
>
>
>
> > From: Matthias Ringwald <matthias.ringw...@gmail.com>
> > Date: 1. Mai 2011 14:58:18 MESZ
> > To: btstack-dev <btsta...@googlegroups.com>
> > Subject: Fwd: RFCOMM
>
> > short note on the RFCOMM channel assignment problem: I've decided to add a "get persistent channel nr for service with name" in BTdaemon and change the register RFCOMM service back to directly accepting a channel nr - which provides a way to handle channel numbers on a full OS, while simplifying the API for embedded systems (as you can just pick your RFCOMM channels directly). More on that after it got implemented.
>
> > best
> > Matthias
>
> > Begin forwarded message:
>
Matthias Ringwald
the Bluetooth module generates a lot of HCI_EVENT_PACKET and a bunch of them are handled by BTdaemon but also forwarded to the client app, that's fine so far.
the rfcomm-cat example gave me data from my GPS as RFCOMM_DATA_PACKETs the last time I tried. Does the other side send data? :)
please check out /tmp/hci_dump.pklg on your iPhone (copy to mac and use PacketLogger or Wireshark on all other platforms) and post it here.
Best
Matthias
TreadMiller
XX XX...
I see several Undecoded Event Types. Here's those expanded:
[13:22:28.965] [HCI EVENT] Undecoded Event Type -
Undecoded Event Type -
Parameter Length: 0 (0x00)
Event type unknown to LogHCIEvent.
[13:22:29.651] [HCI EVENT] Undecoded Event Type -
Undecoded Event Type -
Parameter Length: 1 (0x01)
Event type unknown to LogHCIEvent.
[13:22:29.926] [HCI EVENT] Undecoded Event Type -
Undecoded Event Type -
Parameter Length: 15 (0x0F)
Event type unknown to LogHCIEvent.
[13:22:29.929] [HCI EVENT] Undecoded Event Type -
Undecoded Event Type -
Parameter Length: 3 (0x03)
Event type unknown to LogHCIEvent.
[13:22:30.031] [HCI EVENT] Undecoded Event Type -
Undecoded Event Type -
Parameter Length: 2 (0x02)
Event type unknown to LogHCIEvent.
Also there's this one:
[13:22:33.880] [L2CAP RECEIVE] Command reject
Command reject
Identifier: 0x10
Size: 6 (0x0006)
Reason: 0x0002 - Invalid CID in request.
Local CID: 0x0040.
Remote CID: 0x0043.
Data [Handle: 0x000c, Channel ID: 0x0001, Length:
0x000a (10)]
0x00000000: 0A 00 01 00 01 10 06 00 02 00 40 00 43
00 :..........@.C.
Here's the full log collapsed.
[13:20:14.388] [HCI EVENT] Undecoded Event Type -
[13:22:27.042] [HCI COMMAND] [F402] Undecoded Testing Command
[13:22:28.921] [HCI EVENT] Undecoded Event Type -
[13:22:28.930] [HCI COMMAND] [0C03] Reset
[13:22:28.933] [HCI EVENT] Command Complete - Reset
[13:22:28.939] [HCI COMMAND] [1009] Read Device Address
[13:22:28.941] [HCI EVENT] Command Complete - Read Device Address
[13:22:28.941] [HCI COMMAND] [1005] Read Buffer Size
[13:22:28.944] [HCI EVENT] Command Complete - Read Buffer Size
[13:22:28.944] [HCI COMMAND] [0C18] Write Page Timeout
[13:22:28.945] [HCI EVENT] Command Complete - Write Page Timeout
[13:22:28.945] [HCI COMMAND] [0C1A] Write Scan Enable
[13:22:28.952] [HCI EVENT] Command Complete - Write Scan Enable
[13:22:28.952] [HCI EVENT] Undecoded Event Type -
[13:22:28.952] [HCI COMMAND] [0C13] Change Local Name
[13:22:28.957] [HCI EVENT] Command Complete - Change Local Name
[13:22:28.958] [HCI COMMAND] [0C24] Write Class of Device
[13:22:28.964] [HCI EVENT] Command Complete - Write Class of Device
[13:22:28.965] [HCI EVENT] Undecoded Event Type -
[13:22:28.973] [HCI COMMAND] [F440] Undecoded Testing Command
[13:22:29.010] [HCI COMMAND] [0405] Create Connection: XX-XX-XX-XX-
XX-XX
[13:22:29.023] [HCI EVENT] Command Status - Create Connection
[13:22:29.650] [HCI EVENT] Connection Complete - status: 0x00 -
Connection Handle: 0x000C - XX-XX-XX-XX-XX-XX
[13:22:29.651] [HCI EVENT] Undecoded Event Type -
[13:22:29.652] [L2CAP SEND] Connection Request
[13:22:29.724] [HCI EVENT] Max slots change - Max slots: 0x5 -
Connection Handle: 0x000C
[13:22:29.786] [L2CAP RECEIVE] Connection Response
[13:22:29.797] [HCI EVENT] Number of Completed Packets - Packets:
0x1 - Connection Handle: 0x000C
[13:22:29.877] [L2CAP RECEIVE] Connection Response
[13:22:29.877] [L2CAP SEND] Configuration Request
[13:22:29.879] [L2CAP RECEIVE] Configuration Request
[13:22:29.879] [L2CAP SEND] Configure Response
[13:22:29.908] [HCI EVENT] Number of Completed Packets - Packets:
0x2 - Connection Handle: 0x000C
[13:22:29.926] [L2CAP RECEIVE] Configure Response
[13:22:29.926] [HCI EVENT] Undecoded Event Type -
[13:22:29.929] [RFCOMM SEND] SABM for channel 0
[13:22:29.929] [HCI EVENT] Undecoded Event Type -
[13:22:29.930] [HCI EVENT] Undecoded Event Type -
[13:22:29.976] [RFCOMM RECEIVE] UA for channel 0
[13:22:29.976] [RFCOMM SEND] UIH Parameter Negotiation COMMAND
[13:22:29.981] [HCI EVENT] Number of Completed Packets - Packets:
0x2 - Connection Handle: 0x000C
[13:22:30.031] [RFCOMM RECEIVE] DM for channel 0
[13:22:30.031] [HCI EVENT] Undecoded Event Type -
[13:22:33.775] [L2CAP SEND] Disconnection Request: Channel
ID(0x0001) - Src CID (0x0043) - Dest CID (0x0040)
[13:22:33.776] [HCI EVENT] Undecoded Event Type -
[13:22:33.851] [L2CAP RECEIVE] Disconnection Response
[13:22:33.851] [HCI EVENT] Undecoded Event Type -
[13:22:33.851] [L2CAP SEND] Disconnection Request: Channel
ID(0x0001) - Src CID (0x0043) - Dest CID (0x0040)
[13:22:33.856] [HCI EVENT] Number of Completed Packets - Packets:
0x2 - Connection Handle: 0x000C
[13:22:33.880] [L2CAP RECEIVE] Command reject
[13:22:43.651] [HCI EVENT] Undecoded Event Type -
[13:22:43.651] [HCI COMMAND] [0406] Disconnect - Connection Handle:
0x000C - Reason: 0x13
[13:22:43.653] [HCI EVENT] Command Status - Disconnect
[13:22:43.735] [HCI EVENT] Disconnection Complete -
ConnectionTerminatedByLocalHost (0x16) - Connection Handle: 0x000C
[13:22:43.735] [HCI EVENT] Undecoded Event Type -
[13:22:43.778] [HCI EVENT] Undecoded Event Type -
[13:22:43.928] [HCI EVENT] Undecoded Event Type -
On May 5, 3:53 pm, Matthias Ringwald <matthias.ringw...@gmail.com>
callum
to pair with my mbw-150 watch? The basic bluetooth function isnt
discovering it after installing btstack?
Matthias Ringwald
in your log, this line isn't good:
[13:22:30.031] [RFCOMM RECEIVE] DM for channel 0
My guess is that the RFCOMM channel you've specified doesn't exist. channels are from 1-31.
I can have a quick look at packet log, but please provide them in PacketLogger or hcidump format, the textual representation like below lacks almost all information.
Best
Matthias
Matthias Ringwald
You basically do the same with the mbw-150 using BTstack as you would with another Bluetooth Stack. I actually would suggest to first play around on a desktop computer using the BlueCove JSR82 implementation in Java - there are some python bindings as well.
As people have been asking for RFCOMM server functionality for long, I suspect that the mbw-150 is the one to open an RFCOMM connection and not the other way round. I guess you should read the clock's manual. :)
Best
Matthias
tharun mathew
Matthias Ringwald
--
You received this message because you are subscribed to the Google Groups "btstack-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
To post to this group, send email to btsta...@googlegroups.com.
Visit this group at http://groups.google.com/group/btstack-dev.
For more options, visit https://groups.google.com/d/optout.