Doctor (A-party)

PDA Host

Buetooth Host Controller

Patient (B-party) PIB Mary

The PDA sends an HCI_Inquiry command to its Bluetooth Host Controller; the Host Controller responds with an HCI_Command_Status_Event, which acknowledges it has received the command.Then the Host Controller sends out a series of Inquiry packets (ID packets containing the General Inquiry Access Code).

Every device within range (which is in discoverable mode) should hear these packets and respond with an FHS (Frequency Hopping Synchronization) packet. These packets contain all the information the PDA needs to connect with the responding PIBs.

The Host Controller sends the inquiry response information up to the PDA in one or more inquiry result events.

Developing & Deploying...

HCI Implementation Guidelines

There are many possible architectures which can be used to implement a robust PIB system. We have already noted that for the PIB itself, a single processor architecture could provide the cheapest option, but for the rest of the system, it is likely that applications will run on a separate host processor. Let's consider the two processor architectures as defined in Bluetooth Specification Version 1.1 (Part H:1 Introduction, page 584). The communication occurs using HCI (Host Controller Interface) packets. The host is the processor controlling the Bluetooth Host Controller.

Figure 10.9 shows command and dataflows between a host and Host Controller. The dotted line connecting commands with command complete events shows how the command completes correspond with commands. For every command packet sent, there is a command complete event packet. The command complete events may not come back in the same order that the commands were sent. Some commands, such as the inquiry command, may take many seconds to implement, so it is likely that sometimes the host will want to send more commands while waiting for a command complete event. This means the host must be able to send commands and handle the command complete events synchronously.

If a Bluetooth link is established and data is being exchanged, then data from the host can cause flow control events to come back from the Host Controller indicating how empty the data buffers are. This needs to be processed at a higher priority to avoid the Host Controller's buffers overflowing with a consequent loss of data.


Figure 10.9 Command and Dataflows between a Host and Host Controller

Figure 10.9 Command and Dataflows between a Host and Host Controller

Because events are sent to the host at the same time as the host is sending data and commands to the Host Controller, an asynchronous communications architecture is needed.

The reason why HCI transport also has to be robust is that HCI packets carry a length field, used to calculate where the end of the packet is. If at any moment in time the counting of bytes is lost due to loss of a byte(s), then the synchronization has to be reestablished, at the expense of losing a complete HCI packet.

Version 1.1 of the Bluetooth specification was published with three HCI transports defined: UART, RS232, and USB. RS232 has not been widely implemented, with most Bluetooth adopters seeming to view it as over-complicated. UART was defined for communication between chips on a PCB and does not perform well over links which are subject to errors (as the cabled serial port links to many PCs are). USB is tolerant of errors, but many Bluetooth host controller devices do not implement USB as it is quite a complex protocol. There is currently an HCI working group that is defining a new HCI transport, which, amongst other improvements, provides error detection and correction across serial links.

The HCI_Inquiry_Result_Event illustrates one aspect of Bluetooth which is likely to provide a challenge for applications developers. Some Host Controller devices will gather all inquiry responses together in the Host Controller, and just send one HCI_Inquiry_Result_Event to the host. Other Host Controller devices will send the host an HCI_Inquiry_Result_Event for every inquiry response received.While still other Host Controllers may even send duplicate events if they receive multiple responses from the same device.

If you are able to specify a complete system including hardware and software, you could write an application which was tailored to the behavior of one Host Controller. However, this makes for a system which can be limiting and difficult to upgrade. In the PIB system, one of the requirements is the ability to use a variety of legacy equipment, so there is a requirement to support whatever Host Controller devices fit onto existing equipment.

Whenever writing Bluetooth applications you should be aware that the Bluetooth specifications often include optional parts, and thus behavior is likely to vary subtly between different manufacturer's Bluetooth components. If you want your applications to be robust and useful across a wide range of platforms, you must cater for optional parts of the specification.

Was this article helpful?

0 0

Post a comment