RFCOMM Control Information
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 apparently do allow signals to be read and set e.g. RTS, and Break; errors conditions to be read e.g. overrun; and they also allow access to the link's MTU settings.
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
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 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.
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
send and receive control and break signals as well as RLS (line error) information. See
. In both cases one can access the socket via our BluetoothClient.Client property to set/get those properties.
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.