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
53
CONN-GUIDE-BT740_v0.2
8 MULTIPOINT PROTOCOL
8.1 Introduction to Multipoint Protocol
This chapter describes a packet based messaging interface which a host uses to send commands,
receive responses, receive asynchronous events and exchange multiplexed data with the Bluetooth serial
module, henceforth described as the module.
The module consists of a Bluetooth chipset with an approved Bluetooth stack which allows simultaneous
connections to a minimum of one slave and, depending on hardware build and conditions, up to seven
slaves. It also allows connections to multiple profiles to one or more slaves. Hence this document adopts
a concept of channels instead of slave connections. You can also view these channels as logical data
pipes.
The term ‘host’ in this document refers to any entity which is a source of command messages, sink for
response/event messages, and both source and sink for multiplexed data packets.
To further eliminate any confusion, when the terms ‘command message’ and ‘confirm message’ are used,
it implies a message from the host to the module. Likewise the terms ‘response message’ and ‘event
message’ imply a message from the module to the host.
There is an implied client/server model in the protocol described in this document and the host should
ensure that no new commands issue to the module until after a response is received for that command or
an appropriate timeout. If multiple commands are sent, they queue and process only after the oldest
command processes. Confirm messages do not have the same restrictions. Data packets do not follow
that model. It is likely that asynchronous event messages are sent before response messages but that
should not be taken as a signal to issue new commands. The only exception to this is when an unknown
command receives; in this case the transaction terminates by an UNKNOWN_COMMAND event.
This document does not describe how the packets are physically exchanged between the host and the
module. The transport medium could be either UART or USB. It also does not describe the format of any
envelope that may be required to reliably and quickly transfer the message packet between the host and
module.
This implies that when the packets proposed in this document are processed, they are assumed not to
contain any errors by either peer entities.
8.2 Flow control & Data Integrity
The transport mechanism streams in nature. If the transport medium is USB, then flow control and data
integrity is inherently provided by the USB protocol.
If the medium is UART, then it is assumed that there is a minimum of a five wire interface: RX, TX, CTS,
RTS, and GND. Any host attached to the UART of the module strictly observes CTS/RTS hardware
handshaking. Packet data integrity may or may not be provided depending on the build. For a UART
transport media, guaranteeing data integrity is at the severe expense of data throughput.