Device Discovery Explained in .NET framework Generate PDF417 in .NET framework Device Discovery Explained

1.3.9 Device Discovery Explained generate, create none none on none projects Microsoft .NET Compact Framework Bluetooth splits none none the 2.4-GHz band into 79 channels, with the intent that all devices on a single piconet use exactly one of these channels at a time. Of these 79 channels, 32 are also used for detecting nearby devices and establishing connections.

An inquiring device transmits inquiry messages on. Bluetooth Essentials for Programmers these channels, none for none and a discoverable Bluetooth device periodically listens for and replies to the inquiry messages. Inquiring for Nearby Devices To conduct a device inquiry, the inquiring device divides the 32 channels into two sets, called train A and train B. These sets are more or less randomly chosen, and a discoverable device is no more likely to be listening on a channel in train A than it is on a channel in train B.

Next, the inquiring device transmits an inquiry message on each channel in train A, listening for a response each time it changes channels. If there is no reply, this is repeated at least 256 times (more if the inquiring device has active SCO connections). Once train A has been exhausted, the inquiring device repeats the process for train B, alternately transmitting inquiry messages and listening for responses for each channel in train B.

A single transmit/listen cycle for each channel takes 625 s. Since there are 16 channels in each train, and each train is repeated 256 times, the inquiring device spends 625 s 16 256 = 2.56 s in each train before switching.

By default, a single device inquiry switches trains four times for a total device inquiry lasting 2.56 4 = 10.24 s.

Listening for Incoming Connections/Inquiries A discoverable Bluetooth device periodically enters the inquiry scan substate. This is slightly different from the inquiry scan option mentioned in Section 1.2.

1; the inquiry scan option controls whether or not a device ever enters the inquiry scan substate. Two parameters, the inquiry scan interval and the inquiry scan window, determine how frequently a device enters the inquiry scan substate and how much time the device spends there, respectively. By default, the scan interval is 2.

56 s, and the scan window is 11.25 ms. Both of these parameters can be adjusted using HCI commands, although it s generally not a good idea to do so.

Irrespective of the scan interval and the scan window, the channel on which a discoverable device listens for inquiry messages changes every 1.28 s. Each time the channel changes, the next one is chosen pseudorandomly, without trying to predict where an inquiring device is likely to transmit.

. Introduction Looking at the i none for none nquiry and inquiry scan processes side by side, it should be evident that detecting a nearby device is not an instantaneous process. For example, as long as the channel a device is listening on is not in the train that an inquiring device is transmitting on, the two shall never meet. This game of whack-a-mole often continues for many seconds even when the two devices are within inches of each other.

In an effort to alleviate this problem, Bluetooth 1.2 and more recent devices may also enter the interlaced inquiry scan substate instead of the standard inquiry scan substate. In the interlaced mode, each time the device enters the scan window, it listens on two different channels instead of just one.

The intent is to maximize the chance that an inquiring device actually transmits on the channel that matches the discoverable device.. 1.3.10 Bluetooth Stacks Throughout the r none for none est of this book, we will frequently use the term stack to refer to a Bluetooth software environment. A stack simply refers to a collection of device drivers, development libraries, and user-level tools provided by an organization that allows software developers to create Bluetooth applications, and allows users to use the Bluetooth capabilities of a device. In most popular operating systems, there is typically one dominant Bluetooth stack.

For example, GNU/Linux, OS X, Symbian OS, and Palm OS all have a single stack that almost all programmers targeting those platforms use. Since applications written for one stack are not compatible with other stacks, having a single dominant stack usually provides a more consistent and simpler experience for the end user. The major exceptions to this rule are Microsoft Windows XP and Pocket PC, where both platforms have two competing Bluetooth stacks each.

This is discussed more in 4, but the simple way of putting it is to say that creating effective Bluetooth applications for Microsoft devices can be a bigger headache than for other platforms. As we discuss each stack in detail, we ll be most concerned with the development libraries provided and the functionality exposed to software applications. Since Bluetooth is a communications technology, the transport protocols supported by each stack are of particular interest.

All of the stacks introduced in this book and the basic transport protocols supported by each are listed in Table 1.7..

Copyright © . All rights reserved.