Getting On-line Anywhere with Bluetooth and GPRS
Bluetooth and General Packet Radio Service (GPRS) are used widely today to make devices on the move Internet accessible. Bluetooth is a low-range wireless technology that can be made a part of almost any device due to its low cost and power consumption, GPRS offers always-on connectivity to the Internet.
Bluetooth and GPRS can provide standalone network connectivity to your PDA or laptop. Bluetooth roaming enables continuous connectivity when you move your device from one floor of your building to another, and GPRS roaming preserves your Internet connection when you are on the road and move from one service provider's area to another. Figure 1 describes some of these scenarios.
Because Linux runs on a variety of embedded devices including Bluetooth-aware consumer electronics devices, GPRS cell phones and wireless-enabled PDAs, a discussion on how Linux works with Bluetooth and GPRS can be helpful in using and designing such devices.
Bluetooth is a protocol for wireless communication using radio frequency and was conceived as a replacement for cables. It supports speeds of 723 kbps(asymmetric) and 432 kbps (symmetric) and it can be used to transfer both data and voice. Bluetooth devices have a range of about 10 meters (30 feet).
BlueZ is the official Linux Bluetooth protocol stack. Although there are other popular Bluetooth implementations on Linux, such as the Affix stack, the rest of this section is devoted to BlueZ.
BlueZ supports the core Bluetooth protocols, including host control interface (HCI), logical link control and adaptation protocol (L2CAP), personal area networking (PAN), service discovery protocol (SDP), synchronous connection oriented (SCO) audio and serial port emulation (RFCOMM). It also comes bundled with a bunch of user space dæmons and configuration tools.
BlueZ supports the different user profiles described by the Bluetooth specification. BlueZ BNEP (Bluetooth Network Encapsulation Protocol) implements Ethernet emulation, which lets TCP/IP run directly over Bluetooth. The BNEP module, together with a user mode dæmon called pand implements Bluetooth PAN. BlueZ RFCOMM allows serial port applications, such as terminal emulators, and protocols, such as point-to-point protocol (PPP), to run unchanged over Bluetooth. The RFCOMM module, along with a user mode dæmon called dund implements Bluetooth dial-up networking.
The Bluetooth specification defines the use of UART and USB transport mechanisms to transfer HCI packets between a Bluetooth device and a host system. For UART interfaces, the main protocols available to encapsulate HCI packets are H4/UART and Blue Core Serial Protocol (BCSP). Whereas H4 serves as the standard method for transmitting Bluetooth data over a UART interface, BCSP is a proprietary protocol from CSR that supports error checking and retransmission. BlueZ supports both H4 and BCSP. If the Bluetooth chip used on your board has a UART interface to the host processor and is programmed to encapsulate HCI packets using BCSP, you need to inform the BlueZ stack of this. Do so using hciattach: hciattach ttySx bcsp, where x is the UART channel number connected to the Bluetooth chip. The BlueZ UART link driver hci_uart now talks to the chip using BCSP and passes the Bluetooth data to and from the BlueZ stack.
BlueZ also has a link driver hci_usb, which supports USB Bluetooth devices. The driver uses the services and data structures provided by the Linux kernel USB core to manage data transfers asynchronously between the host and the Bluetooth USB device. As per the Bluetooth specification, the hci_usb driver uses the corresponding USB pipes—control, interrupt, isochronous or bulk—to transport different types of Bluetooth data—HCI commands, HCI events, SCO audio or asynchronous connectionless data). The Belkin Bluetooth USB adapter is an example Bluetooth USB device that works with BlueZ.
BlueZ also supports the transfer of audio data to devices such as Bluetooth headsets. An application on the host Bluetooth device uses BlueZ SCO APIs to send audio data to the headset. The audio data pumped through the SCO APIs has to be in a format understood by the headset, for example, A-law pulse code modulation (PCM) format is used for the Sony Ericsson HBH-30 Bluetooth headset. If the Bluetooth chipset on your host device has a PCM interface connected to another audio source, you might have to configure the chipset to receive the SCO audio over its HCI interface rather than over its PCM interface.
BlueZ utilities can be used to set up Bluetooth connections. For example, the hcitool utility can be used to initiate an inquiry process and discover the names and Bluetooth addresses of units within range. You then can set up a PAN or a dial-up connection to a discovered Bluetooth device using pand or dund. The sdptool program can be used to register or search for a service, say, printing or networking. The important BlueZ user space dæmons, utilities and kernel modules, along with a brief description of each, are listed below:
hciconfig --a: examine the HCI interface.
hcitool -f hci0 scan --flush: discover other Bluetooth devices within range.
hciattach ttySx any [baud]: attach an encapsulation method (H4, BCSP), baud rate and a flow control mechanism to the serial port connected to the Bluetooth device.
hcidump: HCI sniffer.
hcid: HCI dæmon.
/etc/bluetooth/hcid.conf: HCI dæmon configuration file used by hcid that specifies link mode (master or slave), link policy, inquiry and scan mode and so on.
/etc/bluetooth/pinDB: BlueZ PIN database.
sdpd: service discovery protocol dæmon.
pand: runs TCP/IP over Bluetooth (--listen for the server, --connect<bluetooth_address> for the client).
/etc/bluetooth/pan/dev-up: pand invokes this script when bringing up TCP/IP. This script can contain a command like ifconfig bnep0<ip_address>up to configure the Bluetooth interface with an IP address.
dund: runs PPP over Bluetooth RFCOMM (--listen for the server, --connect<bluetooth_address> for the client).
BlueZ kernel modules:
bluez: the BlueZ core layer.
l2cap: L2CAP implementation.
hci_uart: UART transport driver (supports H4/BCSP).
hci_usb: USB transport driver.
bnep: Ethernet emulation (used along with pand).
rfcomm: serial port emulation.
SCO: support for voice transport over Bluetooth.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Validate an E-Mail Address with PHP, the Right Way
- Tech Tip: Really Simple HTTP Server with Python
- Build a Skype Server for Your Home Phone System
- Why Python?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Reply to comment | Linux Journal
12 min 27 sec ago
- Reply to comment | Linux Journal
1 hour 2 min ago
- Not free anymore
5 hours 4 min ago
8 hours 51 min ago
- Reply to comment | Linux Journal
8 hours 59 min ago
- Understanding the Linux Kernel
11 hours 14 min ago
13 hours 44 min ago
- Kernel Problem
23 hours 46 min ago
- BASH script to log IPs on public web server
1 day 4 hours ago
1 day 7 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?