How to Talk Smart

Wouldn't you like to know how many minutes of usable talk-time remained in your cellular phone battery, video cam-corder, lap-top computer or any of the many other battery powered devices you use? As embedded systems are increasingly being targeted at battery-powered devices, questions like this will be asked more frequently. To date, the solutions that have been offered range from the simple idiot light, indicating when the power supply reaches a certain level of discharge, to the sophisticated power management software present on laptop computers.

As battery technology continues to evolve, discharge characteristics of the various battery chemistries have become increasingly difficult to predict. What kind of battery chemistry, how many times the battery has been discharged or charged, and self-discharge characteristics are at the root of predicting successfully how long a battery will last. Compounding this problem is the fact that without knowledge of the batteryıs history, it is nearly impossible to calculate predictive data with any accuracy. Clearly, the best solution to this problem is for the battery to keep track of these variables itself. Recognizing this as a problem area for most battery powered devices, Duracell and Intel have jointly created a standardized battery/power system interface and placed it into the public domain. This article describes this host-battery interface specification.

"Smart Battery" Overview

A "smart battery" exhibits an increased level of self-awareness, knowing such things as what its chemical composition is, what the manufactured capacity is, what types of controls are needed when charging, and when to terminate operation due to low voltage. By allowing the battery to monitor its own critical parameters, a host system can ask and obtain very accurate predictive data on how long the battery will last at a given load. Using this information, the host can control its operation and/or inform the user how much more life they can expect.

In reality, a smart battery is simply one component of a system consisting of several different components. In this article I use the term "host" to refer to the system master. Most likely, this host is a CPU that is further decomposed into several entities or tasks. Figure 1 depicts an example system overview and shows the general information flow between the various components.

The power subsystem is the task or process that is responsible for controlling system power. This power subsystem includes such things as: determining which battery should be used if several are available; issuing charging commands to the charger; and letting the host know when loss of power is eminent. The code that supports the smart battery interface in Figure 1 is generally responsible for the physical layer interface of the smart bus. Typically, this physical layer interface is made up of the code that is the least portable because it directly connects with the physical hardware. In the following sections, I will discuss the external interface and give an overview of the commands that comprise the smart battery command specification. Then I will present an overview of the functions of the battery selector and charger.

Smart-Battery System Bus

The smart battery system bus (SMBus), as described in the system management bus specification, is a two-wire interface that closely resembles the Philips Semiconductors I2C interface.1, 2 This interface provides for a bidirectional interface that allows smart bus peripherals such as battery chargers, batteries, and the host all to communicate with each other. The major modifications made to the I2C protocol in support of the SMBus were time outs and protocol additions, in order to allow for multiple bus masters (such as originators). Device time outs allow for an error condition to be generated if a receiver does not respond to a sender within a fixed time period. This feature is important because often a receiver will issue a no-acknowledge (No-Ack) to a sender, for example, during a byte read. To indicate the end of a read sequence using device time outs, the receiver can simply not respond to the sender and thereby signal the occurrence of an error. The second modification mentioned above involves how a device that is normally a slave (as a battery pack would normally be) would inform the host of errors or operational problems, such as unsolicited messages originating from a slave device.

While Iım discussing the SMBus, it is worth mentioning what may be one of its major limitationsıthe sheer number of required interconnects. As the size of battery power devices continue to decline, the two, three, or four bus contact points called out in the specification will probably be impossible to supply in the future. This will result in either single wire, multiplexed, or modulated power sources as space constraints become more of a factor. Because of the probable changes in the physical interface, it is probably safe to say that the I2C bus, while a good model for the present, probably won't be for the future.

smBus Physical Layer Interface

The physical layer interface is broken into eight possible command formats for any given SMBus device. These command formats are defined as: Quick CommandSend Byte Receive ByteWrite Byte/Word Read Byte/WordProcess Block ReadBlock Write

Of these eight command formats, this articleıs focus is on the Write Byte/Word, Read Byte/Word, Block Write, and the Block Read commands. These commands are the primary message types used for communications between the host and smart battery. In fact, the additional commands are actually a subset of the these four command types (except for the Process message type).

For each of these formats, the Slave Address (what is referred to as the command byte in the I2C protocol) is typically defined as one of the following: Slave Address:Description: 0001000xSmart Bus Host (Host-Device) 0001001xSmart Battery Charger 0001010xSmart Battery Selector 0001 011xSmart Battery 0001100xSmart Bus Alert

Response where x is the position of the Read/Write bit. As you would expect, this bit indicates whether this message type is a read (1) or a write (0). For the Read byte routine, the sender must initially check for an idle state and provide for a time-out mechanism in case the receiver were to issue an error. If this read is a word read, then an Acknowledge (Ack) must be issued after the first byte is received so that the second (least significant) byte of the word can be received. In either case, after the desired number of bytes has been received, a No-Ack is issued to the sender to terminate the transfer. The primary difference between a Word/Byte Read and a Block Read is that the receiver will receive a count of the number of bytes to follow. Once this byte count is acknowledged by the receiver, the sender begins sending data continuously until either done or a No-Ack is received from the sender.

When transmitting data to the smart battery or charger, the process is pretty much the opposite of receiving. When sending a word instead of a byte, the sender will look for an Ack from the receiver and then send the least significant byte of the word. When performing a block write, the sender will first send the total number of bytes that will be sent. In all cases, the sender must constantly be aware of the time-out periods to ensure that the data transfer should continue.

Overview The goal of the smart battery and its associated protocol is to provide a system capable of providing predictive information on the capacity of a battery, independent of the battery chemistry or self knowledge of operational current consumption. This information cannot be maintained by the host device unless the battery is permanently connected to the device. Because most battery powered devices have replaceable batteries, the need for this usage history must reside within the battery itself. By implementing the ideas proposed in the smart battery specification, the battery would know what its capacity is, what its current state of charge is and what the rate of discharge is. Additionally, the host system can obtain information about the battery's chemistry type, the number of charge/discharge cycles the battery has been through, the battery's internal temperature and so on. This information can be relayed to the user to show exactly how much battery life can be expected and how long it will take to charge the battery. The information can also allow, for example, the manufacturer to stamp their batteries, so if device is designed to require a nickel metal hydride battery, the host device can ensure that this kind of battery is attached before normal operation begins.

Messages between the Host-device and smart-battery Once a host is aware of the presence of a smart battery, it usually configures the operational parameters so that the battery and host are talking the same language. This configuration process typically consists of issuing a battery mode command that specifies how to report the capacity (in mAh or 10mwH). This command also responds with information such as whether an internal charge controller is present (and the battery will control its own charging), the battery is requesting a conditioning cycle, the battery is the primary or secondary battery, or other tidbits of information.

One of the more desirable features, at least from a software writer's point of view, is the fact that the host can program the battery to automatically broadcast alarm messages in case the remaining capacity or time threshold is exceeded. This capability allows the embedded device to set the alarm condition, and then simply go about the normal operational activities. Monitoring the battery in a continuous fashion is not neccessary because the battery will let us know when capacity or time is getting short. Of course, the host will want to periodically issue a command to determine the remaining capacity or time-to-empty. When you are using batteries that support the smart battery specification, all this information is simply an I/O read away rather than requiring a complex calculation involving battery discharge rates, voltage, temperature, cycle counts, and a multitude of other contributing factors. Most of the commands required for deterministic power control have been specified in the smart battery specification shown in the list in Table 1.

Selecting from Multiple Smart Batteries As smart batteries proliferate, one can only wonder what will happen when more than one is connected to a common power system. Let's face it, the potential for power-system anarchy is pretty good when multiple devices all compete to supply power and/or their operational information. To address this potential problem, a smart battery system adjunct specification was created. This specification, referred to as the selector specification, defines a consistent way for batteries to be connected or disconnected from the power bus by a host device. To select between multiple batteries (as is common in laptop PC applications, for example), the power subsystem uses information available from the power selector messages to determine which batteries are present, what their relative state of charge is, and whether or not external power is available. The selector messages are responsible for such things as isolating batteries during charging, ensuring that critical messages and information are routed to the appropriate entity (host or charger), and handling the switch over of power from one battery to another or from battery to external power. In total, the specification provides control for up to four batteries.

The two messages that the selector specification defines to support this functionality are defined in Table 2. These two messages are both a collection of bits that allow the system to define which batteries are smart batteries (in case some aren't), which batteries can be used to power the system, which are connected to the charger, and which battery to use next.

Controlling a Smart Battery Charger A smart charger allows the battery to control its own charging. After all, who knows better than the battery itself how it should be charged? Ideally, a smart battery would tell the charger how to adjust the charging cycle based on its current state of discharge, current temperature, charge/discharge cycle count to date, and a slew of other relevant data. Optionally, if a battery didnıt control its own charging, the charger would request the battery chemistry, manufactured capacity, and related data and then choose an optimal charging algorithm based on this information. By strictly controlling the manner in which the battery is charged, the maximum potential of the battery can be achieved. Additionally, the charger will know such things as when (if ever) to re-condition the battery. The charger will be able to tell the user when the batteryıs usable life has been reached or simply limit the host device to operating with certain types of batteries or manufacturers. As previously mentioned, a smart battery can be configured to automatically generate an alarm message whenever predetermined conditions are met. This feature can be used to automatically control the batteryıs changing. By letting the battery automatically issue alarm messages to the charger, the burden of constant monitoring is greatly reduced or eliminated. While this feature would not necessarily be a great feature for a dedicated charger, it does significantly reduce the complexity of controlling a charging cycle by a host device that may be attempting to perform a number of other tasks.

THE LAST WORD

As portable electronic devices increasingly depend on batteries for power, a common and comprehensive way of communicating with them will undoubtedly keep coming up. While the specifications mentioned in this article are by no means the last word on the subject, they do provide fertile ground on which to launch discussions. James M. Flynn is a senior staff engineer with Ericsson Inc. in Research Triangle Park, NC. He received his MS in Computer Science from Florida Institute of Technology and has been programming embedded systems for more than nine years. Jim can be contacted at flynn@egertp.ericsson.se.

References

1. Intel System Management Bus Specification, Revision 1.0, February 15, 1995.
2. For a good overview of the I2C interface see Programming the I2C Interface by Mitchell Kabn, Dr. Dobb's Journal, Iss. 189, June 1992. Other sources I2C Bus Specification, Philips Corporation. Intel System Management Bus Specification, Revision 1.0, February 15, 1995. Duracell/Intel Smart Battery Data Specification, Revision 1.0, February 15, 1995. Intel Smart Battery Selector Specification, Revision 0.9, April 13, 1995. Duracell/Intel Smart Battery Charger Specification, Revision 0.95a, February 15, 1995. David Maliniak, Smart Batteries Come On-Line, Wireless Systems Design, Vol. 1, No. 2, April 1996.