Text 1.The Android Execution Environment

Applications in Android are a bit different from what you may be used to in the desktop and server environments. The differences are driven by a few key concepts unique to the mobile phone environment and unique to Google’s intentions for Android. As you write applications for an Android handset, you will use these concepts to guide the design and implementation of the application:

Limited resources

Mobile phones today are very powerful handheld computers, but they are still limited. The fundamental limitation of a mobile device is battery capacity. Every clock tick of the processor, every refresh of memory, every backlit pixel on the user’s screen take energy from the battery. Battery size is limited, and users don’t like frequent battery charging. As a result, the computing resources are limited— clock rates are in the hundreds of MHz, memory is at best a few gigabytes, data storage is at best a few tens of gigabytes. Throughout this book we will talk about the mechanisms included in Android to optimize for these limited resources.

Mobile mashups

In the desktop Internet world, mashups make it very easy to create new applications by reusing the data and user interface elements provided by existing applications. Google Maps is a great example: you can easily create a web-based application that incorporates maps, satellite imagery, and traffic updates using just a few lines of JavaScript on your own web page. Android extends that concept to the mobile phone. In other mobile environments, applications are separate, and with the ex-ception of browser-based applications, you are expected to code your applications separately from the other applications that are running on the handset. In Android you can easily create new applications that incorporate existing applications. Chapter 13 focuses on these mobile mashups.

Interchangeable applications

In other mobile software environments, applications are coded to access data from specific data providers. If you need to send an email from a Windows Mobile application, for example, you code explicit references to Pocket Outlook’s email interface, and send the email that way. But what if the user wants to use another email client?

Android incorporates a fundamental mechanism (Intents) that is independent of specific application implementations. In an Android application, you don’t say you want to send email through a specific application; instead, you say you want to send an email through whatever application is available. The operating system takes care of figuring out what application can send emails, starts that application if needed, and connects your request so the email can be sent. The user can substitute different browsers, different MP3 players, or different email clients at will, and Android adapts automatically.

Text 2. Universal Serial Bus (USB)

 

Universal Serial Bus (USB) is an industry standard developed in the mid-1990s that defines the cables, connectors and communications protocols used in a bus for connection, communication and power supply between computers and electronic devices.

USB was designed to standardize the connection of computer peripherals (including keyboards, pointing devices, digital cameras, printers, portable media players, disk drives and network adapters) to personal computers, both to communicate and to supply electric power. It has become commonplace on other devices, such as smartphones, PDAs and video game consoles. USB has effectively replaced a variety of earlier interfaces, such as serial and parallel ports, as well as separate power chargers for portable devices.

The design architecture of USB is asymmetrical in its topology, consisting of a host, a multitude of downstream USB ports, and multiple peripheral devices connected in a tiered-star topology. Additional USB hubs may be included in the tiers, allowing branching into a tree structure with up to five tier levels. A USB host may implement multiple host controllers and each host controller may provide one or more USB ports. Up to 127 devices, including hub devices if they present, may be connected to a single host controller. USB devices are linked in series through hubs. One hub—built into the host controller—is the root hub.

A physical USB device may consist of several logical sub-devices that are referred to as device functions. A single device may provide several functions, for example, a webcam (video device function) with a built-in microphone (audio device function). This kind of device is called composite device. An alternative for this is compound device in which each logical device is assigned a distinctive address by the host and all logical devices are connected to a built-in hub to which the physical USB wire is connected.

USB device communication is based on pipes (logical channels). A pipe is a connection from the host controller to a logical entity, found on a device, and named an endpoint. Because pipes correspond 1-to-1 to endpoints, the terms are sometimes used interchangeably. A USB device can have up to 32 endpoints, though USB devices seldom have many endpoints. An endpoint is built into the USB device by the manufacturer and therefore exists permanently, while a pipe may be opened and closed.

There are two types of pipes: stream and message pipes. A message pipe is bi-directional and is used for control transfers. Message pipes are typically used for short, simple commands to the device, and a status response, used, for example, by the bus control pipe number 0. A stream pipe is a uni-directional pipe connected to a uni-directional endpoint that transfers data using an isochronous, interrupt, or bulk transfer:

• isochronous transfers: at some guaranteed data rate (often, but not necessarily, as fast as possible) but with possible data loss (e.g., realtime audio or video).
• interrupt transfers: devices that need guaranteed quick responses (bounded latency) (e.g., pointing devices and keyboards).
• bulk transfers: large sporadic transfers using all remaining available bandwidth, but with no guarantees on bandwidth or latency (e.g., file transfers).

Text 3. Adaptive Algorithms for Finite Impulse Response Filters

 

Adaptive filters generally consist of two distinct parts:

a filter, whose structure is designed to perform a desired pro­cessing function, and an adaptive algorithm for adjusting the parameters (coefficients) of that filter. The many possible combi­nations of filter structures and the adaptive laws /governing them/ lead to a sometimes bewildering variety of adaptive filters.

We focus on what is, perhaps, the simplest class of filter structure: linear filters with a finite impulse response (FIR). Note that the filter output is a linear combination of a finite number of past inputs. The filter is not recursive (i.e., conta­ins no feedback). This property leads to particularly simple adap­tive algorithms.

Having specified the filter structure it is next required to design an adaptive algorithm for adjusting its coefficients. We are to consider adaptive laws whose objective is to minimize the energy of the filter output (i.e., the output variance or the output sum of squares). The need to minimize this particular cost function arises in many applications involving least-squares es­timation, such as adaptive noise canceling, adaptive line enhan­cement, and adaptive spectral estimation.

We are to present two adaptive algorithms for FIR fillers: the recursive least-squares (RLS) algorithm and the Widrow-Hoff least-mean-squares (LMS) algorithm. The LMS algorithm has gained considerable popularity since the early 1960s. Its simplicity makes it attractive for many applications in which computational requirements need to be minimized. The RLS algorithm has been used extensively for system identification and time-series analysis. In spite of its potentially superior performance, its use in signal processing applications has been relatively limited, due to its higher computational requirements. In recent years there has been renewed interest in the RLS algorithm, especially in its "fast" (computationally efficient) versions. The RLS algorithm has been applied to adaptive channel equalization adaptive array processing and other problems.

The concept of adaptation in digital filtering has proven to be a powerful and versatile means of signal proces­sing in applications where precise a priori filter design is im­practical. For the most part, such signal processing applications have relied on the well-known adaptive finite impulse response (FIR) filter configuration. Yet, in practice, situations commonly arise wherein the nonrecursive nature of this adaptive filter results in a heavy computational load. Consequently, in recent years acti­ve research has attempted to extend the adaptive FIR filter into the more general feedback or infinite impulse response (IIR) con­figuration. The immediate reward lies in the substantial decrease in computation that a feedback filter can offer over an FIR filter. This computational improvement comes at certain costs, however. In particular, the presence of feedback makes filter stability an issue and can impact adversely on the algorithm's convergence time and the general numerical sensitivity of the filter. Even so, the largest obstacle to the wide use of adaptive IIR filters is the lack of robust and well-understood algorithms, for adjusting the required filter gains. The classes of algorithms to be currently under development are to be explored those based on minimum mean-square-error concepts, and another which has its roots in nonlinear stability theory. The basic derivation of each will be pre­sented and certain aspects of performance examined. Other key de­sign concerns, such as the fact that certain algorithms require the use of specific filter structures, will also be to be illumi­nated.