User's Manual

Enhanced Class 1 Bluetooth v2.1 Module
User’s Guide
Americas: [phone] Option 2
Europe: [phone]
Hong Kong: [phone]
www.lairdtech.com/wireless
146
CONN-GUIDE-BT740_v0.2
Whatever OOB means are chosen, it implies that some externally generated key has to be added to the
trusted device database in the device.
The module caters for this link key addition using the CMD_TRUSTED_DB_ADD command when in the
multipoint protocol mode and the AT+KY command when in the AT protocol mode.
13.8.4 Throughput Analysis
The following are factors that affect overall data throughput:
 Baudrate – The baudrate at the UART determines the maximum throughput and has a theoretical
maximum of 80% of the baudrate if using ‘none’ parity and one stopbits. That theoretical maximum
reduces to around 67% if parity is enabled along with two stopbits.
 Radio utilization – The radio utilization in the sense that at any time, up to three non-transient
operations could be active. The radio could be servicing on-going connections, it could be scanning
for inquiries, and it could be scanning for incoming connections. For the latter two, the scanning
operation has a duty cycle and the worst case of 100% has a major impact on the throughput as
the radio is time shared between the connections and the scanning operations.
 RF connection quality –If the quality is bad and there are many retries of packets, then the
throughput can drop to close to zero before the connection automatically drops. For Basic Rate
connection packets, the best throughput limits to around 600 kbps in asymmetric data transfer
falling to around 400 kbps for symmetric transfers when using Base Rate RF packets. This can
triple when using EDR packets.
 RFCOMM frame size – The size of the RFCOMM frame, which according to the BT spec can be a
value between 23 and 32767. The bigger the value the better, but the incremental gain around
1000 and above is negligible for embedded Bluetooth stack with limited RAM. This value sets via S
Register 11 in multipoint mode and 9011 in AT mode
 MP packet payload size – In the multipoint protocol which is packet-based, the size of the MP
packet payload has an impact and in fact the packets should be as large as possible, and yet the
MP protocol limits the maximum payload to 253 bytes due to the length field of the packet being
only a single byte.
The charts that follow, where actual throughput is plotted against the RFCOMM frame size, show that in
multipoint mode the packet structure and scanning for inquiries and paging have a significant impact on
the throughput.
With regards to MP mode, the UART host should optimize performance by sending data to transmit in as
large packets as possible and completely disabling all scanning operations by setting S Registers 4 and 5
to zero.
It is entirely possible for the host to bombard the module with the worst case scenario of three byte
packets with just one data byte payload. In this case, if too many of these packets are sent and the
framesize is large (such as 64 and above), it is entirely possible for the module to lose the connection by
resetting. This happens because the module panics when it runs out of memory. On the rare
occasion that this happens, it is possible to mitigate this issue by increasing the value of S register 81. By
default this value is set to 30%.
Testing by Laird shows that with a framesize larger than 64 and sending a storm of three byte packets
(with one byte payload) and the default value of 30%, it is possible to panic the module into a reset.
Testing with a value of 50% in S Reg 81 solves the problem. But increasing the value of S Register 81
has an impact on how many simultaneous SPP connections can be sustained.