click here for article

“All power corrupts, but we need the electricity.”

The origin of that quote is unknown, but whoever said it was a genius. In today's power-hungry wireless world, the key is keeping the power to a minimum — But how?

In the beginning

Bluetooth was designed as a low-power system from the beginning. In that vein, many future Bluetooth devices will be battery-powered. For Bluetooth to be widely accepted in the marketplace, it must stay true to that discipline.

But what exactly does “low power” mean? From the consumer's point of view, there is no real understanding of Bluetooth power consumption. Today, consumers do not know what to look for on the side of the box to determine which Bluetooth device is better. This stems partly from the fact that Bluetooth is such a new technology, consumers have not had sufficient time to study these choices. But it also stems from the fact that Bluetooth is not a single, readily definable thing — rather it is targeted to be pervasive across multiple applications and, in essence, be many things. This is the beauty of Bluetooth: its flexibility and portability. But it's also a marketing problem.

Confusion beyond the end user

Confusion exists at the technical level as well. Data sheets typically contain values pertaining to current usage, but these values are often static numbers. They are usually average values for static modes of operation that may or may not apply to the final products. Or they may simply be missing relevant information. In either case, it is often difficult to have an apples-to-apples comparison of chips, chipsets or modules.

For example, no standard method exists for determining the average current usage of a Bluetooth device. Yet, in an effort to bring some commonality to the technology, one can follow a basic method to understand how technology and devices get defined.

First, know your product

The best way to understand current consumption in a Bluetooth product is to realize that Bluetooth is simply an adjective, not a noun. Nothing is “Bluetooth”; things are Bluetooth-enabled. These include Bluetooth headsets, Bluetooth-enabled laptops, Bluetooth-enabled PDAs or Bluetooth input devices. The user models for Bluetooth devices are contained within the primary device, not Bluetooth. After all, nobody cares how much current a USB cable uses.

In some cases, Bluetooth will dominate current consumption in a device. This is especially true for simple devices such as a Bluetooth headset or a Bluetooth mouse. Headset consumers will want to know the old standard benchmarks like talk time and standby time. For the mouse, they will want to know how often to change the battery. These are easy values to determine once a product exists, but much more difficult to extract during the early stages of product development. It will be important to have accurate current consumption estimates for these devices so that the description on the box lives up to the consumer's expectations. It will also be important to define current consumption estimates for product developers — everybody needs to be on the same page. Such information drives technical decisions on battery type, cost and marketability, as well as ergonomic considerations such as product size and shape.

However, in some Bluetooth systems (e.g. laptops and appliances using AC power), Bluetooth will not be a noticeable drain on the system, especially if the device spends most of its life in low-power modes like sleep, or is plugged directly into the wall.

Thus, when assessing the power requirements of a system, more than one level must be analyzed. As a general rule, the two levels of abstraction, the Bluetooth level and the user level, are the guiding light.

Details, details, details

Generally, Bluetooth devices do… well, Bluetooth functions. These functions include transmitting and receiving data while connecting and being available for connections from and to other devices.

Bluetooth uses a time-division duplex (TDD) multiple-access scheme that is based around 625-µs time slots. Connections may be point-to-point or point-to-multipoint with a master and one or more slave devices. The master transmits packets addressed to specific slaves, and slaves may only respond starting in the next available slave-to-master time slot. Communications between devices is performed using the 14 defined packet types (see Table 1) that encompass one, three, or five time slots. The Bluetooth specification is defined such that there is a minimum of 234.5 µs of time between subsequent packets including a ±10 µs uncertainty window for reception.

Within a time slot, current consumption-related events may occur that vary power requirements. For example, the three events discussed below may occur with different values depending on a number of criterion. At the beginning of a time slot, the synthesizer is enabled along with the microprocessor or baseband digital hardware. Later, after the synthesizer has completed tuning, the receiver or transmitter is enabled. Finally, after the data are sent or received, the active digital logic and radio will shut down. Depending on the length of the packet, different current profiles occur. These are easily measured using standard lab equipment. Some example profiles are shown in Figure 1.

What is most important to analyze in these current profiles is the average current. For single-slot packets, the current is averaged over 625 µs. Similarly, for three- and five-slot packets, the current is averaged over 1875 µs and 3125 µs, respectively. More complicated scenarios can be constructed using these profiles. Table 2 lists eight active mode cases for measuring average current consumption.

It's all about packets

An audio, or SCO, connection uses HV1, HV2, or HV3 packets. All three types are single-slot packets, and each is 366 µs long. There are differences among them in various parameters. The first difference among the types is the amount of coding. The HV1 packet contains 10 bytes of audio, while the HV2 packet contains 20 bytes and the HV3 packet contains 30 bytes. The second difference is the time between packets.

Because an SCO connection carries a fixed 64 kilobits of audio data per second, the total number of packets required per second depends on the packet type. An HV1 SCO connection uses the full bandwidth of the piconet while an HV3 connection uses only one-third of the bandwidth. From the current consumption point of view, a large difference exists between these two scenarios.

First, look at the HV1 connection. In this case, the master transmits a packet on one time slot and then receives it on the next. Inversely, the slave receives on one time slot and transmits on the next. The equation for both a master and slave in an HV1 connection is:

In the HV3 connection, the master transmits on one time slot, receives on the next, and then does nothing for the next four time slots. The equation for this case is:

In the HV3 connection, however, the slave has slightly different requirements than the master during the non-SCO time slots. This is because slave devices are required to listen for a master transmission in every master-to-slave time slot. The equation for the slave HV3 connection is:

Figure 1 shows a simplified current profile where only two current levels exist during a time slot. One level is during reception or transmission while the other is during the rest of the time. If, for example, these two currents are 50 mA and 20 mA respectively, then the following applies:

OneSlotRx = OneSlotTx = (366 • 50 mA + 259 • 20 mA)/625 = 37.6 mA.

SlaveRxACErr = (88 • 50 mA + 537 • 20 mA)/625 = 24.2 mA

ActiveNoRxTx = (625 • 20 mA)/625 = 20 mA

Plugging these values into the previous equations results in:

HV1 master = 37.6 mA
HV1 slave = 37.6 mA
HV3 master = 25.9 mA
HV3 slave = 27.3 mA

What becomes obvious is that a power bias favors the master in the HV3 connection because doing nothing uses less current than listening for a master transmission.

Similarly, equations can be created for data or ACL connections.

Any type of model may be created using these types of building blocks. The key is to measure the eight active mode current profiles shown in Table 2 and plug them into the appropriate equations. DM and DH packets are essentially the same length for a given number of slots, so it doesn't matter which one is measured. In each active case (with data), the measurements should be done for full packets. To fully characterize the system, transmit measurements should be done at minimum and maximum power levels. This may not matter for Class 2 (+4 dBm) and Class 3 (0 dBm) devices, but it will be a significant factor for Class 1 (+20 dBm) devices.

More measurements

Measurements for standby currents use a procedure similar to the one used for active currents. Two measurements should be made in this simplified case. These are shown in Table 3.

The equations for page or inquiry scanning are more complicated than those for active modes. The equation for R1 page scan (11.25 ms window with 1.28 s interval) is:

If the average current during the 11.25 ms reception window is 50 mA and the average current while asleep is 10 µA, the average current during R1 page scanning is 450 µA.

Now that a method is known for measuring average current consumption of Bluetooth active and standby modes, it is possible to move to current consumption for profiles and applications.

After all that, know the user too

One of the differences between Bluetooth-enabled devices and their wired ancestors is that a Bluetooth-enabled device may take on different roles from time to time. For example, a Bluetooth-enabled laptop will be able to deliver compressed CD quality audio to Bluetooth-enabled stereo headsets at one moment, and later (or even simultaneously) be used for synchronizing with a PDA. These two events use Bluetooth as a transport mechanism, but fundamentally they have different current usage scenarios. Understanding the end-user model is the key to understanding Bluetooth current consumption at the product level.

In the case of a cell phone, most technical people, as well as consumers, understand that two relevant numbers appear on the side of the box: talk time and standby time. If those numbers are large enough, then the customer buys the phone. If not, the consumer will find one to suit his needs. To the average consumer, this may be hard to understand for Bluetooth devices because there isn't yet a similar analogy for these Bluetooth devices. Furthermore, similar issues exist for the metrics of human interface devices (HIDs), such as mice or keyboard, and for a Bluetooth-enabled PDA or laptop.

User scenarios are built from basic building blocks. These may be as low level as simple transmission, reception, or nothing; or they may be higher-level scenarios such as full throughput data connections or HV3 audio connections. Basic building blocks may be combined to produce SCO or ACL connections, as well as non-active modes like park, sniff, page scanning or inquiry scanning. Within the ACL connections, there may also be single or multislot packets and different power classes of operation (where Class 1 is +20 dBm, Class 2 is +4 dBm, and Class 3 is 0 dBm).

Take the math to the mouse

An example of such a conundrum can be shown using a Bluetooth-enabled mouse. A typical user scenario for a mouse may be: 10% of the business day the mouse is in use, 50% of the business day the mouse has been used within 60 seconds, 40% of the business day the mouse has not been used within 60 seconds. After hours, the mouse is not in use and PC is turned off.

In this case, the business day would be eight hours. For simplicity, consider after hours as nighttime (16 hours per day) and weekends. Translating the above usage scenario into Bluetooth terminology results in the following: 10% of the business day the mouse is in sniff with 10 ms interval, 50% of the business day the mouse is in sniff with 100 ms interval, 40% of the business day the mouse is in sniff with a 1 s interval. After hours the mouse is in R2 page scan (2.56 s interval and 11.25 ms window). Averaging these numbers over an entire week, results in: 2.3% of the time the mouse is in 10 ms sniff, 11.9% of the time the mouse is in 100 ms sniff, 0.5% of the time the mouse is in 1 s sniff, 76.3% of the time the mouse is in R2 page scan.

The results for the mouse-user scenario shown in equation 1 become:

Average current = (0.023 • A) + (0.119 • B) + (0.095 • C) + (0.763 • D)

The values of A, B, C and D depend on the specific Bluetooth chip(s) or module. For the sake of argument, let's choose two hypothetical Bluetooth chips. The main differences between these two “chips” are that Chip 2 uses 25% current in receive and transmit modes and has 50 µA more leakage current than Chip 1. This being the case, the following scenario applies.

Param.

Desc.

Chip 1

Chip 2

A

10 ms sniff

6 mA

8 mA

B

100 ms sniff

313 µA

378 µA

C

1 s sniff

57 µA

111 µA

D

R2 page scan

180 µA

270 µA

Based on these parameters, two questions may be asked:

  1. Which mode dominates the total current consumption?
  2. What is the actual difference in total current consumption?

When values for A, B, C and D are plugged into Equation 1, the average currents are: chip 1 average current = 142 + 37 + 5 + 136 = 322 µA, chip two average current = 190 + 45 + 11 + 206 = 453 µA.

Chip 1's average current is about 70% of Chip 2's. On closer inspection of these equations, it is obvious that for both chips, two of the modes dominate nearly 90% of the total current used in the system (10 ms sniff and page scanning), while two of the modes use nearly none. This is the type of information that is helpful to a system designer trying to understand where to optimize current consumption in the system. In this case, it is obvious that optimizing the one-second sniff case would not produce any significant benefit.

ID

68µs

POLL

126 µs

NULL

126 µs

FHS

366 µs

DM1

366 µs

DH1

366 µs

DM3

1626 µs

DH3

1622 µs

DM5

2871 µs

DH5

2870 µs

HV1

366 µs

HV2

366 µs

HV3

366 ms

DV

356 ms

After looking at the equations, it is also obvious that turning the computer off at night seriously reduces the battery life of the Bluetooth mouse because the average current used in page scanning is much larger than that during one-second sniff modes. If the computer were left on during non-business hours, the mouse would remain in the one-second sniff mode most of the time and the average current would become: Chip 1's average current = 143 + 37 + 49 + 0 = 229 µA, Chip 2's average current = 190 + 45 + 95 + 0 = 331 µA. For both chips, this is about 70% of the total with the computer turned off. For the Bluetooth mouse, leaving the computer turned on leads to an increase in battery life — a significant design issue.

Finally, it is possible to determine the average time between battery recharging or replacement by modifying the previous user scenario based on power users, as well as occasional home users.

Conclusions

This method for measurement of average current consumption is a useful tool to select a chipset or module and helps the engineer to understand a product early in the development phase.

It is important to note that many data sheets tend to focus on static, or peak, current measurements. Because Bluetooth is bursty and dynamic by nature, static measurements are a flawed assessment of how the system will perform. It is possible that two different chip or module manufacturers will state a static current measurement of 50 mA for TX or RX operation. The average current could be 50 mA in one case and 12 mA in the other case.

Case

Name

Description

Meas. time

1

OneSlotRx

Reception of DM1 or DH1 packet

625 µs

2

ThreeSlotRx

Reception of DM3 or DH3 packet

1875 µs

3

FiveSlotRx

Reception of DM5 or DH5 packet

3125 µs

4

OnSlotTx

Transmission of DM1 or DH1 packet

625 µs

5

ThreeSlotTx

Transmission of DM3 or DH3 packet

1875 µs

6

FiveSlotTx

Transmission of DM5 or DH5 packet

3125 µs

7

SlaveRxACErr

Slave reception time slot with access code error

625 µs

8

ActiveNoRxTx

Active time slot neither Rx or Tx

625 µs

About the author

Joel Linsky is a senior communications systems engineer at Silicon Wave and is a leader in Silicon Wave's Bluetooth architecture and design. Linsky has 10 years' experience in wireless system design and architecture, specializing in baseband and low-layer software for cellular handsets and Bluetooth. He has designed advanced systems, has several innovations (patents pending) in wireless products, and is an active member in the Radio 1 Improvements and Coexistence working groups. Linsky graduated from the University of California, San Diego (BSEE). He can be contacted at jlinsky@siliconwave.com