RFCOMM control

RFCOMM

TL;DR

Setting the Baud Rate (bit rate) of a Bluetooth RFCOMM connection has no effect on the amount of traffic the link can transfer. The baud rate information exists only to configure a real COM port if one exists are the other end of the link.

Apparently none of the Bluetooth stacks allow the baud rate to be set (they do allow signals to be read and set e.g. RTS, Break; and errors conditions to be read e.g. overrun. They also allow access to the links MTU setting).

Data transfer

When applications on two Bluetooth devices wish to communicate the two radios form a link and then data can be transferred over the connection using the L2CAP protocol. If a serial-emulation type connection is required then RFCOMM can be used and it is 'layered' over the L2CAP connection. See the figure at Alan's Bluetooth Profiles and 32feet.NET document.

Some Bluetooth standard profiles use L2CAP directly, for instance PAN, HID, and HDP. Others use RFCOMM, for instance SPP, OBEX, etc. However The new OBEX profile standard also defines how to use L2CAP directly instead of via RFCOMM presumably for more efficiency and less overhead.

Modem control signals, line-error states, and link settings including bit (baud) rate can be transferred along with data over the RFCOMM connection. Those values are not used by Bluetooth but instead are used only by the real or virtual serial port. For instance setting baud rate does change Bluetooth's transfer speed.

RFCOMM protocol

RFCOMM is defined in Bluetooth standard "RFCOMM with TS 07.10 -- Serial Port Emulation". It is based on ETSU standard TS 07.10 which has the snappy title "Terminal Equipment to Mobile Station (TE-MS) multiplexer protocol". In summary "The 07.10 multiplexer protocol operates between an MS and a TE and allows a number of simultaneous sessions over a normal serial asynchronous interface."

As well as sending the data over the link the TS 07.10 protocol also allows control information about the link to be exchanged. This includes the status of the serial port status signals (RTR, CD, CTS etc), whether a overrun or parity error has occured, and flow-control status. It also can transfer information defining the settings to be used by a real COM port if there is one attached to the remote device, including the number of data bits, what parity mechanism is used and the baud (bit) rate. The data transfer over Bluetooth always uses eight-bit data, no parity, and thus is not affected by these settings.

Commands

The TS 07.10 commands used by RFCOMM are the following. • Test Command (Test) • Flow Control On Command (Fcon) • Flow Control Off Command (Fcoff) • Modem Status Command (MSC) • Remote Port Negotiation Command (RPN) • Remote Line Status (RLS) • DLC parameter negotiation (PN) • Non Supported Command Response (NSC)

From ETSI's TS 07.10

Three are of interest to us here.

• MSC (Modem Status):
  • FC (flow), RTC (ready to communicate), RTR (r/t receive), IC (call), DV (data valid), and Break.
• RPN (Remote Port Neg):
  • Bit rate, Number of Data bits, Number of Stop bits, Parity, Flow control (whether XON/XOFF, RTR, RTC).
• RLS (Remote Line Status):
  • Overrun, Parity, Framing errors.

User access to the control information

As far as I've found, none of the stacks provide baud rate information but some provide line status information.

The Microsoft Bluetooth stack on desktop Windows provides little access to the RFCOMM control information. On a socket one can only access the RFCOMM link's MTU settings. See MSDN - Windows - Bluetooth and Socket Options. On Windows Mobile one can apparently send and receive control and break signals as well as RLS (line error) information. See setsockopt (Bluetooth) and getsockopt (Bluetooth). In both cases one can access the socket via our BluetoothClient.Client property to set/get those properties.

Widcomm apparently exposes the signal changes via an event (virtual CRfcommPort::OnEventReceived ( )) and again one can set and get them (via CRfcommPort::SetModemSignal ( ) and CRfcommPort::GetModemStatus ( )). We do not expose those values.