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
134
CONN-GUIDE-BT740_v0.2
13 MULTIPOINT APPLICATION EXAMPLES
13.1 BLOB Manager
BLOB stands for ‘Binary Long OBject’.
There are many Bluetooth related operations which require large strings to submit to the underlying
Bluetooth stack. For example, friendly names and extended inquiry responses fall into this category.
These strings can be larger than the data packets allowed by the multipoint protocol defined in this
specification.
The BLOB manager is basically a software entity in the module which enables these large objects to be
uploaded into the module in small packets and have them accumulated in a single object.
The BLOB manager can compile time configured to manage up to N objects and unless special firmware
builds are generated, this manual assumes that N is 2. Each BLOB is given a zero based identifier.
BlobID 0 is the first object etc.
A command packet called CMD_BLOBMANAGE exists to manage these BLOBs as required. This
command takes four parameters:
 Parameter 1 – The subcommand ID which tells the BLOB manager what to do.
 Parameter 2 – The BLOB ID
 Oarameters 3 and 4 – 4 byte integer values used as arguments for the subcommand specified in
parameter 1.
The response packet also contains four parameters in exactly the same fashion. Where parameters 1 and
2 echo from the command and parameters 3 and 4 depend on the subcommand.
Recall that this entity manages BLOBs and CMD_BLOBMANAGE is the command to act on them. To get
data into the BLOBs requires the use of data packets with specific dedicated channel numbers. Channel
numbers 0x98 hex to 0x9F hex are reserved for use with BLOBs 0 to 7 respectively.
If data is sent in a data packet with a channel number corresponding to a BLOB that does not exist, then
the data is silently discarded.
Data packets sent to the same BLOB append to any existing data in that BLOB.
Please be warned that sending data to a BLOB reduces memory for other uses, so Laird highly
recommends that the BLOB be cleared or used up as quickly as possible. The Bluetooth chipset has very
limited RAM.
Once data accumulates in a BLOB, CMD_BLOBMANAGE performs various actions on that BLOB which
is specified via parameter 1 described as ‘subcommand ID above. Some of the actions possible are:
 CLEAR – Empties the BLOB identified by the blobID parameter 2.
 GETSIZE – Returns the size of the BLOB in bytes in parameter 3 of the response.
 COPYREAD – Sends a copy of all the data in the BLOB back over the UART in data channel
(blobId+0x98).
 HIDSET – Moves the data to the nonvolatile memory location, which stores custom HID descriptors.
Many HID descriptors can store and each is identified by a zero indexed identifier. In this case, the
HID ID is specified in parameter 3 of the command
 HIDGET – Appends the content of HID descriptor in nonvolatile storage identified by the HID ID in
parameter 1 into the BLOB identified by parameter 2.