Bluetooth at Command Set
Bluetooth at Command Set
The information contained in this document is subject to change without notice. Ezurio makes no warranty of
any kind with regard to this material including, but not limited to, the implied warranties of merchant ability
and fitness for a particular purpose. Ezurio shall not be liable for errors contained herein or for incidental or
consequential damages in connection with the furnishing, performance, or use of this material.
This document contains information that is protected by copyright. All rights reserved. No part of this
document may be photocopied, reproduced, or translated to another language without the prior written
consent of Ezurio.
Other product or company names used in this publication are for identification purposes only and may be
trademarks of their respective owners.
3. UNSOLICITED RESPONSES.................................................................................................................................... 26
3.1 RING.......................................................................................................................................................................... 26
3.2 PIN?........................................................................................................................................................................... 26
3.3 AUDIO ON ................................................................................................................................................................ 26
3.4 AUDIO OFF............................................................................................................................................................... 26
3.5 AUDIO FAIL.............................................................................................................................................................. 26
3.6 ERROR 27................................................................................................................................................................. 26
3.7 PAIR n <bd_addr>................................................................................................................................................. 26
3.8 PAIR 0 <bd_addr> MM ......................................................................................................................................... 26
3.9 RX<string> .............................................................................................................................................................. 26
10 DISCLAIMERS ............................................................................................................................................................. 33
The protocol is similar to the industry standard Hayes AT protocol used in telephony modems
which is appropriate for cable replacement scenarios, as both types of devices are connection
oriented. The telephony commands have been extended to make the EZURiO device perform the
two core actions of a Bluetooth device, which is make/break a connection and Inquiry. Many other
AT commands are also provided to perform ancillary functions, such as, pairing, trusted device
database management and S Register maintenance.
Just like telephony modems, the EZURiO device powers up in an unconnected state and will only
respond via the serial interface. In this state the EZURiO device will not even respond to Bluetooth
Inquiries. Then, just like controlling a modem, the host can issue AT commands which map to
various Bluetooth activities. The command set is extensive enough to allow a host to make
connections which are authenticated and/or encrypted or not authenticated and/or encrypted or
any combination of these. Commands can be saved, so that on a subsequent power up the device
is discoverable or automatically connects.
The device has a serial interface which can be configured for baud rates from 1200 up to 921600,
and an RF communications end point. The latter has a concept of connected and unconnected
modes and the former will have a concept of command and data modes. This leads to the matrix
of states shown below.
RF Unconnected RF Connected
Local Command Mode OK OK
Remote Command Mode ILLEGAL OK
Data Mode ILLEGAL OK
The combinations, ‘Data and RF Unconnected Mode’ and ‘Remote Command and RF Unconnected
Mode’ do not make sense and will be ignored.
Navigation between these states is done using the AT commands which are described in detail in
subsequent sections.
1 All commands are terminated by the carriage return character 0x0D, which is represented
by the string <cr> in descriptions below this cannot be changed.
2 All responses from the EZURiO device have carriage return and linefeed characters
preceding and appending the response. These dual character sequences have the values
0x0D and 0x0A respectively and shall be represented by the string <cr,lf>.
3 All Bluetooth addresses are represented by a fixed 12 digit hexadecimal string, case
insensitive.
4 All Bluetooth Device Class codes are represented by a fixed 6 digit hexadecimal string,
case insensitive.
5 All new Bluetooth specific commands are identified by the string +BTx, where x is
generally a mnemonic of the intended functionality.
2.2 Commands
This section describes all available AT commands. Many commands require mandatory parameters
and some take optional parameters. These parameters are either integer values, strings, Bluetooth
addresses or device classes. The following convention is used when describing the various AT
commands.
<bd_addr> A 12 character Bluetooth address consisting of ASCII characters ‘0’ to ‘9’, ‘A’
to ‘F’ and ‘a’ to ‘f’.
<devclass> A 6 character Bluetooth device class consisting of ASCII characters ‘0’ to ‘9’,
‘A’ to ‘F’ and ‘a’ to ‘f’.
n A positive integer value.
m An integer value which could be positive or negative, which can be entered as
a decimal value or in hexadecimal if preceded by the ‘$’ character. E.g. the
value 1234 can also be entered as $4D2
<string> A string delimited by double quotes. E.g. "Hello World". The " character MUST
be supplied as delimiters.
<uuid> A 4 character UUID number consisting of ASCII characters ‘0’ to ‘9’, ‘A’ to ‘F’ a
‘a’ to ‘f’.
In modems this escape sequence is usually “+++”. “^^^” is specified to avoid confusion
when the module is providing access to a modem.
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
2.2.3 AT
Used to check the module is available.
Response: <cr,lf>OK<cr,lf>
If <U> is not specified, then authentication is as per register 500, otherwise the
connection will be authenticated.
If <Y> is not specified, then encryption is as per register 501, otherwise the connection
will have encryption enabled.
Due to a known issue in the Bluetooth RFCOMM stack, it is not possible to make more than
65525 outgoing connections. Therefore if that number is exceeded, then the connection
attempt will fail with the following response:-
In that case, issuing an ATZ to reset the device will reset the count to 0 and more
connections are possible.
The following RFCOMM based UUIDs are defined in the Bluetooth Specification:-
If <U> is not specified, then authentication is as per register 500, otherwise the
connection will be authenticated.
If <Y> is not specified, then encryption is as per register 501, otherwise the connection
will have encryption enabled.
If both ‘L’ and ‘R’ modifiers are specified then an error will be returned.
If both ‘R’ and ‘L’ modifiers are specified then an error will be returned.
E0 Disable echo.
E1 Enable echo.
Response: <cr,lf>OK<cr,lf>
Or
Response: <cr,lf>ERROR nn<cr,lf>
0 = No prior connection
1 = Connection timeout
2 = Connection attempt cancelled
3 = Normal disconnection
4 = Peer device has refused connection
5 = Service profile <uuid> requested not available on remote
device
6 = Connection has failed
32 = ATH was entered
33 = Incoming connection aborted because too many rings
34 = Unexpected incoming connection
35 = Invalid address
36 = DSR is not asserted
37 = Call limit of 65531 connections has been reached
38 = Pairing in progress
39 = No link key
40 = Invalid link key
255 = Unknown Reason
Response: <cr,lf>a:b,c,d,e<cr,lf>OK<cr,lf>
Where ‘a’ = 0 when not online and 1 when online and Sniff has
been enabled, ‘b’ is the Sniff Attempt parameter, ‘c’ is the Sniff
timeout parameter, ‘d’ is the minimum sniff interval and ‘e’ is
the maximum sniff interval. All parameters ‘b’, ’c’, ’d’ and ‘e’ are
given as Bluetooth slots which are 625 microseconds long
converted from values of S Registers 561, 562, 563 and 564
respectively.
I14 The current boot mode (Only for firmware 1.18.0 and newer)
I15 The maximum length of an AT command, including the terminating
carriage return (only for firmware 1.6.10 and newer)
I16 The size of AT command input buffer
I33 Version number of Multipoint application (Note: ATI is provided for
compatibility in multipoint mode, other AT commands are not available).
I42 State information. Where the response values are as follows:
13 = NotOpen
14 = OpenIdle
15 = Ringing
16 = OnlineCommand
172 to 177 = waiting for connectable and/or discoverable where
The value part ‘m’ can be entered as decimal or hexadecimal. A hexadecimal value is
specified via a ‘$’ leading character. For example $1234 is a hexadecimal number.
When S register values are changed, the changes are not stored in non-volatile memory
UNTIL the AT&W command is used. Note that AT&W does not affect S registers 520 to 525
or 1000 to 1010 as they are updated in non-volatile memory when the command is
received.
Please note that as disconnection time can vary, this register only
guarantees the minimum delay. Note that for invalid addresses specified in
the ATD command, the “NO CARRIER” response will be immediate. See S
register 560 for specifying disconnect max timeout.
S506 1 0..1 Enable/Disable echoes. The ATEn command also affects this.
S507 0 0..2 When set to 0, a connection can be dropped using ^^^ escape sequence
only and the state of DSR line is ignored.
When set to 1 a connection can be dropped using EITHER the ^^^ escape
sequence OR the DSR handshaking line. When set to 2, a connection can
only dropped using a deassertion of DSR. Mode 2 provides for the highest
data transfer rate.
If the status of the DSR line is to be conveyed to the remote device as a
low bandwidth signal then this register MUST be set to 0, otherwise a
deassertion of DSR will be seen as a request to drop the Bluetooth
connection.
This register affects S Register 536 – see details of 536
The seventh most significant digit, can be 0,1 or 2, and is used to specify
the type of device class filter.
When 0, it specifies no filtering.
When 1, it specifies an AND mask and all 24 bits are relevant
When 2, it specifies a filter to look for devices with matching major device
class which occupies a 5 bit field from bits 8 to 12 inclusive (assuming
numbering starts at bit 0). All other 19 bits MUST be set to 0.
S517 20 2..61 Inquiry Length in units of seconds. This parameter is referenced by the
AT+BTI command
S518 8 0..255 Maximum number of responses from an inquiry request. This parameter is
reference by the AT+BTI command. If this number is set too high, then
AT+BTI will return ERROR 27. For a particular firmware revision,
determine the effective maximum value by trial and error. That is, set to a
high value, send AT+BTI and if ERROR 27 is returned, then retry with a
smaller value. This effective max value will remain unchanged for that
particular firmware build.
S519 500 100..6000 When S507>0, and in a connection, DSR can be used to change from data
to command state by deasserting the DSR line for less than the time
specified in this register. This value is rounded down to the nearest 100ms
S520 Depends 1200..115200 Change to a standard baud rate. The effect is immediate and in fact the OK
on device will be sent at the new baud rate. Only one of the following baud rates are
– see accepted: 1200,2400,4800,9600,19200,28800,38400,57600,115200.
comments
If S register 525=1, then the maximum baud rate is limited to 115200
The default is 9600 for EZURiO’s BISM and Embedded Modules and 115200
for other EZURiO Bluetooth devices.
For the Go blue Activator variant of the module this register is read only
See S Register 526 for further information.
S521 See 1200..921600 Change baud rate to non-standard value. EZURiO’s modules support any
Comment baud rate. The only limitation is the integer arithmetic involved, which
may adjust the applied rate slightly. If the internally computed baud rate
is more than 2% offset from the desired input value, then an ERROR will
be returned and the old baud rate will prevail. To inspect the actual baud
rate, do ATS521? See also section 8 of this manual.
S521 should only be sued for non-standard baud rates. For standard baud
rates use S520.
The effect is immediate and in fact the OK will be sent at the new baud
rate.
The default is 9600 for the EZURiO Module and 115200 for other EZURiO
devices.
For the Go blue Activator variant of the module this register is read only
See S Register 526 for further information
S522 1 1 1 = CTS/RTS hardware handshaking enabled
For the Go blue Activator variant of the module this register is read only.
See S Register 526 for further information.
S523 1 1..2 Number of Stop bits
For the Go blue Activator variant of the module this register is read only.
See S Register 526 for further information.
S524 0 0..2 Parity. 0=None, 1=Odd, 2=Even
For the Go blue Activator variant of the module this register is read only.
See S Register 526 for further information.
S525 See 0..1 Apply multiplier of 8 to baud rate internally. This is set to 0 (disabled) by
Comment default for the EZURiO Module/RS-232 Adaptor/Universal RS-232 Adaptor,
and set to 1 (enabled) by default for the EZURiO PC Card.
It is required in the PC Card because the UART chip on the PC Card is
driven by a 14.7456MHZ crystal instead of 1.8432MHz. This means that
when a host asks for a baud rate, in reality it gets a baud rate which is 8
times faster.
If S Register 521 > 115200 then this register cannot be set to 1.
For the Go blue Activator variant of the module this register is read only.
See S Register 526 for further information.
S526 3 1..3 This register specifies a 2 bit mask used to qualify how S Registers 520 to
525 are actioned.
When bit 0 is 1, the new comms parameter affects the UART immediately.
When bit 1 is 1, the new comms parameter is stored in non-volatile
memory
So for example, to change comms parameters, but have them come into
effect only after subsequent power cycles, then this register should be set
to 2, and likewise to affect immediately and yet not have it persist over a
power cycle, the value should be set to 1. Must be set before the baud rate
change.
S530 1000 100..15000 Reconnect delay when configured as master in pure-cable-replacement
mode. This value is rounded down to the nearest 100ms. See S Register
505 and 543 also
S531 0 0..3 Specifies the mode on connection establishment.
0 = Normal, that data is exchanged between UART and RF
1 = LOCAL_COMMAND. UART input is parsed by the AT interpreter and RF
data is discarded
2 = REMOTE_COMMAND. RF input is parsed by the AT interpreter and
UART data is discarded. If S Reg 536 is not 1 then this register cannot be
set to 2 and an ERROR will be returned
3=LOCAL_COMMAND. UART input is parsed by the AT interpreter and
incoming RF data is sent to the host using the RX<string> asynchronous
response.
4=LOCAL_COMMAND and on the RF side, the GPIO is automatically sent
when there is a change in input. See section 9.5 for more details.
S532 0 0..7 If non zero then on every connection, and SCO channel (audio) will be
initiated. Bit 0 for HV1, Bit1 for HV2 and Bit2 for HV3
S533 1 0..2 If set to 1 then left LED follows RI state, if set to 2 then it follows the state
of DSR and if 0 the LED is not driven and GPIO5 is available as a user I/O.
This register will not necessarily be effective immediately after changing
the value. It must be saved to non-volatile memory using AT&W and will
operate as expected after an ATZ or a power cycle.
S534 1 0..2 When set to 0, GPIO4 is available as user i/o
If set to 1 then right LED follows DCD state. If set to 2 then the led
behaves as per setting 1, but in addition, when not in a connection, if the
device is connectable or discoverable, then the led will blink.
This register will not necessarily be effective immediately after changing
the value. It must be saved to non-volatile store using AT&W and will
operate as expected after an ATZ or a power cycle.
If bits 0..3 and 4..7 are set to 0, then some Bluetooth devices will use that
as a signal to stop sending any data back. For example, Nokia 6310 stops
responding.
The parameter <string> is any string not more than 24 characters long. If a non-visual
character is to be sent then insert the escape sequence \hh where hh are two hexadecimal
digits. The 3 character sequence \hh will be converted into a single byte before
transmission to the peer.
Response: <cr,lf>OK<cr,lf>
The optional parameter <n> is only available for firmware 2.7.0 and newer and is a value
in the range 0 to 7 (up to version 7.18.0). Post 9.18.6 valid values are 0 to 4 inclusive.
ATZ and ATZ0 signify reset and emerge into the current mode (see command ATI14).
ATZ1 to ATZ4 instructs the module to reset and then emerge into the appropriate boot
mode. Note that S Reg 103 specifies the boot mode from cold.
Legal values of ‘n’ are as per the following table. All other values of n will generate a
syntax error response. If ‘n’ is not specified then a default value of 0 is assumed where the
baud rate is NOT changed.
&F0 Medium power consumption, UART baud rate unchanged, Left LED off,
(Default) Right LED = DCD
&F1 Minimum power consumption, UART baud rate set to 9600, Left and Right
LED off
&F2 Minimum power consumption, UART baud rate set to 38400, Left and Right
LED off
&F3 Minimum power consumption, UART baud rate set to 115200, Left and
Right LED off
&F4 Medium power consumption, UART baud rate set to 115200, Left LED off,
Right LED = DCD
&F5 Maximum power consumption, UART baud rate set to 115200,
Left LED=DSR, Right LED = DCD
&F6 Maximum power consumption, UART baud rate set to 115200,
Left LED=DSR, Right LED = DCD
Explicitly set higher baud rates using ATS521=n
Please refer to the “Power Consumption” chapter in the relevant EZURiO device user guide,
for more detailed information of power usage.
The new values are NOT updated in non-volatile memory until the AT&W command is sent
to the EZURiO device.
Response: <cr,lf>OK<cr,lf>
Or
Response: <cr,lf>ERROR nn<cr,lf>
Response: <cr,lf>OK<cr,lf>
Or
Response: <cr,lf>ERROR nn<cr,lf>
Response: <cr,lf>OK<cr,lf>
Or
Response: <cr,lf>ERROR nn<cr,lf>
Response: <cr,lf>OK<cr,lf>
Or
Response: <cr,lf>ERROR nn<cr,lf>
Response: <cr,lf>OK<cr,lf>
The lower layers then go through the process of setting up the SCO channel, and as soon
as a SCO link is established, the following response is asynchronously sent to the host.
<devclass> is a 6 digit hexadecimal number derived as per section “1.2 The Class of
Device/Service Field” of the Bluetooth specification “Bluetooth Assigned Numbers”.
The 24 bits are made of 4 fields briefly described as follows (bit 0 corresponds to the least
significant bit):-
Bits 0-1: Format Type. This field currently only has a value of 00 (i.e. format
type 1).
Bits 2-7: These 6 bits define the Minor Device Class and the value is interpreted
differently based on the Major Device class stored in the next 5 bits.
Bits 8-12: These 5 bits define the Major Device Class as per Table 1.3 in
“Bluetooth Assigned Numbers”.
Bits 13-23: This is an 11 bit field used as a mask to define the Major Service
Class, as per Table 1.2 in “Bluetooth Assigned Number”.
Response: <cr,lf>OK<cr,lf>
Or for an invalid <devclass> value (usually a value which is not 6 hexadecimal characters
long).
Response: <cr,lf>123456
<cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
WARNING: If you make an authenticated connection, the link key gets cached in the
underlying stack. So if you subsequently delete the key using AT+BTD* and immediately
request an authenticated connection to the same device, then the connection will be
established. To ensure this does not happen, either send ATZ after the AT+BTD* OR send
AT+BTD<bd_addr> for each item in the trusted device database.
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>12346789012
<cr,lf>12345678914
<cr,lf>OK<cr,lf>
If the module is waiting for an incoming connection, (entered via AT+BTP, AT+BTG,
AT+BTQ), then it will respond with ERROR 14. To perform the inquiry, send AT+BTX to put
the module back into idle mode.
ERROR RESPONSE
A Bluetooth inquiry process is such that for a single inquiry request a device could respond
many times. To ensure that an address is sent to the host only once for a particular
AT+BTI, an array of addresses is created at the start of each AT+BTI and is filled as
responses come in. This array of addresses is stored in dynamic memory and as such if the
Response: <cr,lf>12346789012,123456
<cr,lf>12345678914,123456
<cr,lf>OK<cr,lf>
Note: Many releases of firmware will return the product name as EZURIO, e.g.
Response: <cr,lf>OK<cr,lf>
When S register 512 = 3, 4, 6 or 7 then it will wait for an incoming connection from the
peer address specified. If the peer address is not 000000000000, then it waits for a
connection from the specified master, otherwise will connect to anyone.
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>12346789012
<cr,lf>OK<cr,lf>
Response: <cr,lf>00000000000
<cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
The <devclass> value specifies an optional fixed length hexadecimal device class code. If
it is not specified, then the device class code is taken from S Register 515.
Response: <cr,lf>OK<cr,lf>
AT+BTPU123456789012
AT+BTPY123456789012
AT+BTPUY123456789012
AT+BTPYU123456789012
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
If S register 512 = 1 and the peer address is NOT 000000000000, then it will periodically
(time specified via S register 505) attempt to connect to the peer address specified. In this
circumstance all commands from the host are buffered in the receive buffer, until a
Bluetooth connection is established with the peer device and it then sends0 the buffer
across. This means that if the peer device is not in the vicinity and will never be there, the
device effectively becomes useless, as in this circumstance a host would want to get
attention of the AT parser to send it new commands – probably one to delete the peer
device.
In this circumstance, a recovery is possible by one of two methods. The first method
assumes that the DTR from the host is connected to the DSR line of the module and the
second method assumes that this connection is absent. In the first method it is enough to
deassert the DTR line from the host and that will abort the autoconnect cycle. The second
method is initiated by resetting the device and then ensuring that the text string
“AT+BT&BISM&<cr>” is sent (where <cr> is the carriage return character). There is
special code which looks out for this magic command and terminates the autoconnect cycle
if it sees it and confirms to the host of that fact by sending an “OK” response.
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>12346789012
<cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
If the service name cannot be set for any reason then an error response ERROR 11 is
returned.
Response: <cr,lf>OK<cr,lf>
or
Response: <cr,lf>ERROR<cr,lf>
Response: <cr,lf>12346789012
<cr,lf>12345678913
<cr,lf>12345678914
<cr,lf>OK<cr,lf>
Response: <cr,lf>0
<cr,lf>OK<cr,lf>
If the device < bd_addr > cannot be reached, or is in non-connectable mode then
Response: <cr,lf>2
<cr,lf>OK<cr,lf>
For a successful pairing, the link key is stored in a volatile cache which is overwritten every
time a new pairing is initiated using this command. The link key can be stored in a non-
volatile database within the device. The list of trusted devices is managed using commands
AT+BTT?, AT+BTT and AT+BTD. The AT+BTT? command produces a list of trusted
Bluetooth addresses (link key is NEVER displayed) and AT+BTT is used to store the cached
link key. The command AT+BTD123456789012 is used to remove the specified device
from the database.
The “OK” response is sent immediately on receipt of the AT+BTW command. On pairing
completion, an unsolicited message will be sent to the host which will be in the form PAIR
n <bd_addr>. See section 3.7 for more details.
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>12346789012
<cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
Response: <cr,lf>OK<cr,lf>
Under special circumstances, unsolicited responses will be sent to the host. They are described in
the following subsections.
3.1 RING
This string is sent to the host when a remote device is initiating a serial port connection.
The fully qualified string is in the form RING 012345678901 where 012345678901 is a 12
digit hexadecimal number which corresponds to the remote device’s Bluetooth address.
This response is sent to the host every 2 seconds until the host either accepts the
connection using the ATA command or rejects it using the ATH command.
3.2 PIN?
This response is sent to the host during a pairing negotiation.
The fully qualified string is PIN? 012345678901 where 012345678901 is the Bluetooth
address of the peer device. In response, the host must supply a pin code which is entered
using the AT+BTK command.
If the peer address does not supply the address in the message exchange, then the
address is specified as 000000000000 – and the paring will proceed as normal.
3.3 AUDIO ON
This response is sent to the host when a SCO channel has been established.
3.6 ERROR 27
This response is sent to the host on power up if the firmware is unlicensed.
3.9 RX<string>
This response is sent to the host when the unit is in online-command mode and S Register
531 is set to 3 and data arrives from a peer.
If the data from the string contains non-visual characters (for example ASCII 0 to 31 and
ASCII 128 to 255), then those characters are translated into a 3 character escape
sequence starting with ‘\’. For example the embedded <cr><lf> sequence would be sent
as the 6 character string \0D\0A.
When the lower layers detect an incoming call, a RING 123456789012 string is sent to the host
every second. The command ATA is used to accept the connection and ATH to reject it.
On connection, if the S0 Register is >=0 then confirmation to the host is in the form:-
CONNECT 123456789012
CONNECT 123456789012 A
CONNECT 123456789012 E
CONNECT 123456789012 AE
Where ‘A’ means authenticated connection and ‘E’ means encryption has been enabled.
When S0 register is -1, neither RING nor CONNECT is sent to the host and the connection is
silently accepted.
If the S 100 register is non-zero, then after the ring indications specified by this register have
been sent to the host, and the host has failed to accept or reject the incoming connection, then an
automatic ‘hangup’ is initiated.
EZURiO Bluetooth modules provide a variety of ways of dropping a connection. One method is
similar to the above, but instead a ^^^ character sequence is used, this is to eliminate ambiguity
when a data call is in progress via a mobile phone which was established using the mobile phone’s
Bluetooth AT modem. The second method involves the host dropping the DTR (DSR from the
module’s viewpoint) handshaking line.
Being able to drop a connection using the escape sequence ^^^ has a severe penalty on data
throughput, in fact, the data rate is of the order of 85kbps instead of about 200kbps. To cater for
this performance hit, the device’s connection drop capability is configurable to be in one of two
modes.
One mode allows for a connection to be dropped using either method, and the other mode allows
for a connection drop using the DTR method only. By default, the device is in former mode. This
mode is selected using the S507 register. See S register table described in an earlier section.
This means that even when a file transfer is occurring and it happens to be full of <Esc Chr>
characters then it is not going to drop into command mode because, when transferring a file it is
going to happen as fast as possible and so the inter character gap is going to be significantly
shorter than the <Guard time>.
The <Esc Chr> character can be changed via the S2 register and the <Guard time> interval can
be specified via the S12 register.
In addition, if S Register 538 is set to 1, then on a successful pairing, the link key will be
automatically saved to the trusted device database. In that case, the asynchronous
message PAIR 0 <bd_addr> has an error code appended at the end to convey the result
of the save operation.
When a connection attempt requires a link key, the trusted device database will be searched
automatically and if one exists will be provided without host interaction. If the link key is not
present, then the connection attempt will be terminated and a NO CARRIER response will be given
to the ATD command.
A typical session to pair, say an Ericsson T68i, to a serial module would be:
• Make the T68i discoverable and send AT+BTI to the serial module. This will result in
inquiry responses from all devices. Make a note of the Bluetooth address of the phone e.g.
123456789012
• On the T68i start pairing procedure by selecting “Phone accepts” in the relevant Bluetooth
menu.
• Send command AT+BTW123456789012 to the serial module
• Confirm that you get an OK response and then PIN? responses on a 2 second interval.
• Enter a pin code on the phone. Say it is 12345768
• Then enter the command AT+BTK=”12345678”.
• The phone will confirm success and likewise the serial module will respond with OK
• On success the serial module will send an unsolicited message in the form of PAIR 0
<bd_addr>
• Send AT+BTT to the serial module so that the pairing information is stored in the non-
volatile database.
• Confirm that the link key has been stored by sending the command AT+BTT?. This will
result in a list of all devices paired with the module.
• To device 1 send ATI4, it will respond with the local Bluetooth address. E.g. 123456789001
• To device 1 send AT+BTP. It will become discoverable and connectable.
• To device 2 send AT+BTW123456789001 and it will respond with OK
• Then on both devices you will see PIN? asynchronous responses
• To both modules send AT+BTK=”12345678”
• On success the serial module will send an unsolicited message in the form of PAIR 0
<bd_addr>
• The pairing link key, is at this stage, in volatile memory, so send AT+BTT to both.
• The two units now have pairing information which will survive a power cycle.
Error Description
01 Register not recognised
02 Value for register is out of range
03 Incoming call NOT pending
04 No call to connect to. This error code has meaning for ATO only
05 Syntax Error
06 Empty String
06 Device Class could not be stored
08 Invalid Device Class Code
09 Invalid Bluetooth Address
10 Could not set Service or Friendly name
11 PS Store Write
12 PS Store Read
13 Not Idle
14 Incorrect Mode
15 Already Scanning
16 Pairing is already in progress
17 Not USED
18 Not USED
19 Not USED
20 Not safe to write to Non-volatile Store - Ongoing Bluetooth Connection
21 Link Key Cache is Empty
22 Link Key Database is Full
23 Malloc returned NULL - Resource Issue
24 Remote Address same as Local Address
25 Connection Setup Fail, DSR Not asserted
26 Unauthenticated licence
27 Max Responses (See S Register 518) too high. Memory allocation error
28 The length of Pin in AT+BTK is too long
Invalid Ring count specified for S Register 0 or 100. If S0<>0 and S100<>0
29
then S0 must be < S100
30 ADC Error
31 Analogue Value cannot be read as it is set for output
32 Analogue Value cannot be written as it is set for input
33 S Register Value is invalid
34 Both L and R modifier cannot be specified in ATD command
35 Invalid Major Device Class – valid value in range 0x00 to 0x1F inclusive
36 Pairing in progress – Command cannot be actioned – try again later
Invalid Sniff parameter specified.
37 E.g. new Attempt value greater than MinInterval. Solution is to first increase
MinInterval and re-enter the Attempt value.
38 Get Remote Friendly name Failed
39 Failed to change mode to Multipoint
40 7 Bit mode requires parity to be even or odd
In fact, as long as the equation BAUDRATE * 0.004096 produces an integer value, there will be
0% error in clocking for that baud rate.
So it is possible to set a baud rate that a PC cannot cope with, and in that circumstance it is
virtually impossible to communicate with it.
To cater for this circumstance, the EZURiO device will come out of reset using 9600,N,8,1 comms
settings for exactly 750 milliseconds and then revert to the comms parameters as per the S
Registers.
If the host sends the string !<BISM>!<cr> where <cr> is the carriage return character within
that 750ms period, then the module will remain at 9600,N,8,1 and will also configure itself using
factory default S Register values.
For example, the feature could allow a device to make an outgoing connection if RI is in one state,
and be ready for an incoming connection in the other.
The module has a number of general purpose digital I/O pins. The direction of these are specified
via S Reg 610.
When S Reg 531 is set to 4 at both ends of the connection, then on connection, any changes in the
states of the inputs at one end will be transmitted to the peer, which will then reflect those states
on the appropriate I/O pins if they have been configured as outputs.
It is recommended that the value of S Reg 610 at one end be the one’s complement of the other
end. That way, inputs at one end are mirrored at the other end and vice versa.
Note that due to inherent latency of Bluetooth transmission, expect the change of state to be
delayed. This value is typically 100ms and can be much more if the quality of the link is bad which
results in many retries.
Please check with EZURiO Ltd for the most recent data before initiating or completing a design.