Specifications are available via bluetooth org, however registration is required for full access. White-papers can be downloaded and give a good overview. Many different protocol layers exist, and therefore bluetooth is not bluetooth, more has to be specified to get something working. Additionally different implementation exist. The HCI (Host controller interface) is the link to the hardware. Unfortunately it is not clear what additional core protocols are included in HCI. Some of those core protocols might be below HCI some above. The core protocols are:

Baseband to access the hardware, asynchronous and synchronous link features are supported

LMP (Link Manager Protocol)

Bluetooth logical link control and adaptation protocol (L2CAP)

SDP (Service Discovery Protocol)

On Top of the core protocols there is the Telephony Control Protocol layer containing RFCOMM the Cable Replacement Protocol that allows receiving the AT commands from the AT command protocol to setup a serial link, as in the old days using a modem. But there is also TCS Binary protocol.

Finally on top of those protocols there can be the adopted protocols as TCP/IP, PPP, OBEX, and many more.

The blueZ stack in Linux supports the L2CAP, RFCOMM and SDP protocols.

Working with bluetooth means therefore knowing with what layer to deal with.

However this is often not enough, since the protocols do not describe a behavior of a device. To get such devices with a standard interface and allow them to be exchanged by other devices, bluetooth profiles have been defined that make use of the mentioned protocols. Interoperability is the key word.

Profiles might use and include other profiles. Generic Access Profile (GAP) is a fundamental profile that is used by many other profiles.

The Serial Port Profile (SSP) is used to replace a point to point RS232 cable with a bluetooth link. It makes use of GAP to make the link and the RFCOMM to set the parameters as baud date as well as for the data exchange. Obviously it makes also use of the low layer core protocols.

The device is small but still hand solder-able even it is SMD. It works well for cable replacements but there is nothing built in to ask for PIN for pairing. Therefore if security is an issue, it has to be done on top of it or use an other approach as autoconnect to a given bluetooth mode.

After power up it is in transparent mode so no AT command will be accepted. To go in command mode the send the A+++ sequence. Unfortunately this has also some timing constraints so when typing in using the keyboard it might fail (as when it takes longer than 1 second that is the default time out). gtkterm has the feature to send hex strings that can be edited and the send out in a canonical way so the hex sequence is 41 2b 2b 2b (there is no need to write 0x41). If successful the module returns 0.

An other hurdle is that the AT commands must be upper case and AT will return an E indicating error and not OK. A useful command is AT&V that pops out all registers.

Default settings : 9600, 8bits, 1 stop, no parity, HW flow control Enabled (connect RTS and CTS on the module if connecting device has no hardware handshake.

The register S201 holds Serial Port Device and is the name that appears on bluetooth. It is advised to change it so the device can better recognized ATS201=<new name> and verify it ATS201? Finally store it in non volatile memory AT&W

Laird modules have the SPP (Serial Port Profile) profile implemented. The development board contain an FT232 chip and can therefore be plugged into a PC. A program as gtkterm can be started at /dev/ttyUSB0. Different ways exist how to make the connection

In general ATI<n> are used to get information back from the device.

The S registers can be used to configure the device ATS<n>? reads them ATS<n>=<nn> sets them. ATIS512? shows the status after power up.