Battery Management
System for an Autonomous
Underwater Vehicle
Luke Denton
Supervisor: Associate Professor Karl Sammut
July 2012
Submitted to the School of Computer Science, Engineering and Mathematics in the
Faculty of Science and Engineering in partial fulfilment of the requirements for the
degree of Bachelor of Engineering (Software) at Flinders University – Adelaide
Australia.
Abstract
I have worked on creating a battery management system for an autonomous underwater
vehicle. In order for an autonomous vehicle to be advantageous, it needs to be able to look
after its power source, and get the longest possible run time from it. This means keeping its
batteries within safe operating ranges so that there is no loss of voltage due to one or more
battery cells failing. Using various components, a microcontroller, master gateway controller
and extra fuel gauges, I was able to develop software that would facilitate the
communication of battery usage data from the batteries to the host CPU, using two main
communication protocols along the way; SMBus and CAN bus. I have gained a better
understanding of PIC microcontrollers whilst working on this project, by gaining new
knowledge on the communication protocols used as well as learning how to safely handle
lithium polymer batteries. The software developed isn’t just applicable to this one AUV
either; it can easily be adapted to any other battery powered project by tweaking a few
parameters, depending on the type of batteries used.
Page 1
I certify that this work does not incorporate without acknowledgement any material
previously submitted for a degree or diploma in any university; and that to the best of my
knowledge and belief it does not contain any material previously published or written by
another person except where due reference is made in the text.
Signed ___________________________________
Page 2
Date _______________
Contents
Abstract ...................................................................................................................................... 1
1. Introduction ........................................................................................................................... 4
2. Literature Review ................................................................................................................... 5
2.1 Lithium Polymer Batteries ............................................................................................... 5
2.1.1 Advantages................................................................................................................ 5
2.1.2 Safety Precautions .................................................................................................... 6
2.2 System Management Bus (SMBus) .................................................................................. 7
2.2.1 History ....................................................................................................................... 7
2.2.2 Address ..................................................................................................................... 7
2.2.3 Protocol ..................................................................................................................... 8
2.2.4 Command Types ....................................................................................................... 8
2.3 Smart Battery Data Specification ..................................................................................... 9
2.4 Controller Area Network (CAN) Bus................................................................................. 9
2.4.1 History ....................................................................................................................... 9
2.4.2 Messages................................................................................................................... 9
2.4.3 Frames....................................................................................................................... 9
2.5 bq78PL116 & bq76PL102 ............................................................................................... 10
2.5.1 PowerPump............................................................................................................. 10
2.5.2 SBData ..................................................................................................................... 10
3. Description of Results .......................................................................................................... 11
3.1 The AUV Project ............................................................................................................. 11
3.2 bq78PL116EVM .............................................................................................................. 11
3.3 Cell Simulator ................................................................................................................. 12
3.4 bqWizard ........................................................................................................................ 13
3.5 SMBus ............................................................................................................................ 13
3.6 CAN Bus .......................................................................................................................... 13
4. Conclusion ............................................................................................................................ 14
5. Glossary ................................................................................................................................ 15
6. Acknowledgements.............................................................................................................. 16
7. References ........................................................................................................................... 17
Page 3
1. Introduction
Autonomous Underwater Vehicles (AUV) are becoming increasingly popular for use in
industry for their robustness and intelligence. They’re commonly used for environmental
effects monitoring in the offshore petroleum industry but have applications in many fields
such as military, fisheries, and any other field that requires knowledge of the ocean. AUV’s
make it possible for the ocean to be mapped much more efficiently than previous methods,
and also with greater accuracy, as an AUV will be able to go places that a human on a ship,
or diver in the water, might not necessarily be able to. An AUV is a robot that travels
underwater using a propeller propulsion system, and rudders for steering, following a
designated route or free roaming, mapping the surroundings using various sensors like
SONAR and GPS (when on the surface of the water).
As an AUV will often be off exploring on its own, with no human interaction or control, a
battery management system (BMS) is vital to ensuring the AUV gets the longest possible run
time, whilst also protecting the AUV from any battery problems that may arise. The sole
focus of this document is to provide information on the BMS and the components of it,
which will be used in the AUV. However, the BMS isn’t limited to use in just the AUV, it
could easily be modified for different battery types and different voltage levels to match
with any other battery powered robot or vehicle, autonomous or not.
Page 4
2. Literature Review
Trying to gather information on battery management systems that were already in use was
very hard. All I could find was statements saying that there is a battery management system
in place, not how they worked or what they consisted of. So in reviewing other work, I broke
it down to the things that I would be required to know for the battery management system
of this AUV.
2.1 Lithium Polymer Batteries
Lithium Polymer batteries are, in a basic sense, a Lithium-Ion battery constructed using a
plastic (polymer) electrolyte instead of the usual liquid electrolyte in organic solvent. This
allows them to be made very small, thin, and to almost any shape, unlike a lithium-ion
battery, which needs to conform to a rectangular or cylindrical shape to preserve the gap
between anode and cathode where the liquid is kept. Also, lithium-ion batteries are made
with a metal casing to protect the cells and keep the liquid inside, whereas lithium polymer
batteries don’t have the need for metal casing, as the contents are all solids, so they can just
be wrapped in plastic. Some LiPo batteries are encased in a hard plastic, and others are just
wrapped in soft plastic, reducing weight when compared to lithium-ion, and being
considerably lighter than a NiMH or NiMC battery with similar capacity.
2.1.1 Advantages
Apart from the reduced weight, there are some other very big advantages to using lithium
polymer batteries over other lithium or nickel-metal hydride (NiMH) batteries. The first
being a general lithium battery advantage of no memory effect. This means that the battery
can be charged whenever, without having to fully discharge the battery. This makes lithium
batteries great for portable devices such as phones and computers, as well as for use in
robots, as they can be charged as soon as a mission is complete.
A second advantage of lithium batteries is that they have a very low self-discharge. Selfdischarge occurs while the battery is not in use; they can slowly discharge and lose voltage.
Lithium batteries self-discharge at a rate of 5% per month, compared to a NiMH battery
which will self-discharge at 30% per month, and nickel cadmium (NiCD) batteries, which will
self-discharge at 10% per month. So this is clearly an advantage of lithium over the nickel
based batteries.
The third main advantage of lithium batteries is their improved chemistry, allowing for a
greater energy density, high open voltage potential, and a larger output current, making
them perfect for use with motors and other high power applications. Lithium polymer
batteries improve even more on this chemistry, thanks to the use of the polymer composite
instead of an organic solvent, as mentioned in the previous section. As a result, lithium
polymer batteries have over 20% higher energy density than lithium-ion, and also due to the
difference in packaging, they’re lighter.
Page 5
2.1.2 Safety Precautions
While there are plenty of benefits of a LiPo battery, there are also some safety
considerations and precautions that need to be respected. The first being the cut-off cell
voltage. As you can see in Figure 1 below, if a cell of a LiPo battery drops to 3V, the voltage
will very quickly drop even further, which then means the battery becomes unstable and
there is a high risk of the battery catching fire, within a matter of seconds.
Figure 1: LiPo Discharge Curve (LiPo Discharge Curve,
http://prototalk.net/forums/attachment.php?attachmentid=13&stc=1)
Another safety consideration is temperature. As with all lithium batteries, LiPo’s like heat,
just not too much, so the battery has to be kept from overheating, but also kept from
getting too cold. A third safety consideration is when it comes to handling the LiPo, any
sudden impact to the battery could cause a short between the cells inside the battery, and
fire would then be a real possibility. For the same reason, a puncture to a LiPo is strictly
forbidden. The final important safety precaution is when charging. The LiPo needs to be
charged at a set rate of 1C, and not any faster than this unless specifically specified by the
manufacturer of the LiPo that it is safe to do so. In very simplistic terms, the rating 1C refers
to a rate of discharge of the battery with respect to the current output and amount of time
that that current can be provided.
If a safety precaution is breached, then the battery needs to immediately be isolated and
monitored. Placing it outside on concrete will ensure that nothing will be able to catch fire if
the battery does, and will allow the battery to burn out, and the poisonous fumes to blow
away. Typically what will happen when a LiPo is unstable is it will appear to grow in size, as
gases within the battery begin to expand. The soft covers that hold the battery together will
expand and no longer be a straight rectangular shape, but resemble more of an oval shape.
As the gases build up more, the pressure on the seams of the battery cover will also be
increasing, until they can no longer contain the gas. At this point is when fire can occur, as
the gases rush out of the battery. It’s a very quick and sometimes violent thing to happen,
so extreme caution is paramount even with the slightest thought that the battery may be
damaged. If after 20 minutes or so of the battery having been isolated, it hasn’t blown up or
Page 6
caught on fire, then it is generally safe to assume that the battery is okay. From there the
battery voltage should be checked, and charged if necessary.
These safety precautions are a clear illustration of why a good battery management system
is a must when dealing with LiPo batteries. When properly managed, LiPo’s are a very safe
and very rewarding battery to work with, but when mistreated, they will become unstable,
and dangerous.
2.2 System Management Bus (SMBus)
2.2.1 History
The SMBus is a simple 2 wire communication protocol (3 wires if you include ground), used
to communicate between devices on board a robot. It was first developed by Intel in 1995
to be an inexpensive but powerful form of communication between devices on a
motherboard. Due to its design, commands are usually simply logic implementations. The
SMBus can be thought of as I2C, which is also a 2 wire communication protocol. The only
differences between the two are that SMBus is much more structured, in a sense that I2C
allows differing voltage levels for high and low logic, whereas SMBus has fixed logic levels of
0.8V and 2.7V for low and high respectively. Another difference is with a feature called clock
stretching. An I2C slave device is allowed to stretch the clock of the master device for as long
as it wants, effectively giving the slave device more time to complete a task, however on
SMBus, there is a set time limit, once this time is expired, if there has been no data returned
from the slave device, then the master device will assume that the slave device is in an
erroneous state, and issue a reset to all devices, clearing this error. This feature is
particularly useful in devices such as battery management systems; ensuring one device
doesn’t block communication lines that may be required to report an error with another
battery cell. A third difference that needs to be noted between the two communications
protocols are the speed capabilities. As SMBus is designed to be as inexpensive as possible,
the range of clock frequencies available is from 10 kHz to 100 kHz, compared to I 2C which is
capable of 400 kHz, 2 MHz and as of this year, version 4 of the specification allows up to
5MHz clock frequency. Other than these three mentioned differences, SMBus and I2C can
be thought of as exactly the same communication protocol, and as such, their use is
compatible between devices, where the differences are accounted for.
2.2.2 Address
The SMBus protocol is an address based form of communication. This means that the
master device will send an address over the data line that a device will match with. That
device will then continue to listen on the data line for the rest of the data, and then act
upon it. The other devices will read the address, notice that it doesn’t match with theirs,
and then ignore the rest of the data, until another start bit is received. As the SMBus
transmits in packets of 8 bits (a byte), there would be a maximum number of addresses of
255, however, the first bit of the byte, the MSB, or bit 0, is reserved for the start bit, so that
Page 7
leaves the 7 LSB’s of the byte for addresses, which brings the limit down to 127. This
basically means that one master device can have a maximum of 127 slave devices.
2.2.3 Protocol
The SMBus protocol is typically made up of 2 or more bytes. The first byte is used for the
address, the second byte is used for the command, and the third (and fourth) byte is used
for data (in the case of a write). Figure 1 gives a visual representation of the protocol for a
write command on SMBus.
Figure 2: Write Byte Protocol (System Management Bus Specification Revision 1.1, December 11 1998, Page 22)
As evident Figure 1 above, there are 9 bits in the first byte of the protocol. As most systems
won’t have 127 devices to communicate with, the LSB of the byte can be used as a
read/write indicator; high, or 1, referring to a read command and low, or 0, referring to a
write command. Directly following the write command is an acknowledge bit, this doesn’t
come from the master device, but instead from the slave device, letting the master know
that it has read and acknowledged its address and is ready to receive more data. If there is
no acknowledge received within the specifications clock cycle, then the SMBus will issue a
stop command. As an example of when this condition may arise is when the device with
matching address is busy performing another task, or the data requested by the master
device isn’t available. An acknowledge by the slave device is required after every received
byte from the master device. The final bit is a stop bit, telling the device that data
transmission is completed. Expanding upon this basic protocol can allow the master device
to send data that is larger than one byte, using two bytes instead, and telling the slave that
it should expect two bytes. This is a different command type, called read/write word.
A read command over SMBus isn’t as simple as just swapping the read/write bit. The first
step of the protocol is to issue a write with the command that matches the desired read
command of the slave device. Once this command is acknowledged by the slave device,
then the master issues a re-start with the same address but with the read/write bit set to
read. The slave device will then know that the master is ready to receive data. Just as the
slave device had to acknowledge when data is received from the master, so too does the
master have to acknowledge to the slave that the data is successfully received. Once all data
has been received, the master device will not acknowledge the slave again, but instead issue
a stop command.
2.2.4 Command Types
The SMBus was designed with only a certain number of functions available for use. These
are quick command, send/received byte, read/write byte, read/write word, and block
read/write. However, smart battery management systems typically only implement three of
Page 8
these functions, being read/write word and read block. With these set commands, it makes
it much easier and quicker to implement SMBus communications into a project.
2.3 Smart Battery Data Specification
The smart battery data specification allows battery management system designs to be
standardized. Having a standard across battery management systems means that
communicating with them, using external microcontrollers or microprocessors for example,
becomes much simpler. The functions are already known as they’re based on SMBus, and
using the smart battery data spec allows the commands to be known as well.
2.4 Controller Area Network (CAN) Bus
2.4.1 History
The CAN bus was originally developed by Robert Bosch 1986 for the automotive industry,
and has since been widely accepted in both automotive and aerospace industries. The major
advantage of the CAN bus is that it allows communication between devices at up to 1Mbps,
over a single or dual wire arrangement.
When first implemented in the BMW 850 coupe in 1986, the amount of wires required
within the vehicle reduced by 2km, which lowered the weight of the vehicle by 50kg. This is
quite a substantial loss and shows the secondary benefits of such a communication
protocol; that being it can reduce fuel usage, tyre ware, and environmental impacts.
2.4.2 Messages
The CAN bus is dissimilar to the SMBus and I2C communication protocols as it is not address
based, it is message based. This means that instead of sending out an address
corresponding to one device, it will send out the message to all devices. The devices will
read the message and decide if they’re going to acknowledge and provide data or not. This
gives the CAN protocol the large advantage of allowing extra devices to be added to the bus
without the need for reprogramming of all the devices. A message is sent in a frame and
only after a minimum period of inactivity on the data line by all devices.
2.4.3 Frames
A frame is made up of; a start of frame, arbitration field, control field, data field, CRC field,
ACK field and end of frame. Figure 2 gives a visual representation of a frame.
Figure 3: CAN Bus Data Frame (CAN bus Data Frame, http://www.softing.com/home/images/ia/products/canbus/more-can-bus/data-frame.gif)
Page 9
Arbitration is used for collision handling when two devices (known as nodes) try to send a
message over the bus. Basically, the two identifiers within the arbitration fields of each
nodes’ message is compared, and the one with the lowest value, indicating highest priority,
will be the message that is allowed to go through, the other message will be immediately
halted, and the node will have to try again after another period of inactivity on the data line.
The control field carries the information about how long the data field is going to be in
bytes. The data field is the actual data being transmitted. The reason for allowing a
minimum data length of 0 bytes is because sometimes the message might only be used to
indicate that a process is complete, which doesn’t actually need any data to accompany it,
just a ‘data blank’ message can do this. The CRC field is used for error checking and the ACK
field is used for acknowledging that a message has been successfully received. Finally the
end of frame is used to indicate just that, and is just a sequence of seven logic highs, or
seven 1’s. A 3 bit intermission must follow a message before another node can attempt to
send a message.
2.5 bq78PL116 & bq76PL102
The bq78PL116 is a PowerLAN Master Gateway Controller with PowerPump Cell Balancing
Technology developed by Texas Instruments. Basically, it is a dedicated chip for battery
monitoring. The bq78PL116 chip itself can monitor up to 4 series cells and 4 temperature
sensors. Adding the bq76PL102 battery fuel gauge allows extra series cells to be monitored,
and is connected to the master gateway controller over the PowerLAN communication line.
Using a combination of the two chips, up to 16 series cells can be monitored in a BMS,
making them perfect for use in battery management systems.
2.5.1 PowerPump
One of the great benefits of the master gateway controller is its PowerPump technology.
This allows the chip to perform cell voltage balancing over all battery cells in the pack,
evening out the voltage across all cells. The technology allows battery packs to perform
longer and also increase battery life, as the batteries aren’t unnecessarily over/under
charged. PowerPump is run automatically when the minimum cell voltage difference is
exceeded, so the microcontroller/microprocessor of the robot/vehicle is free to continue
with other tasks.
2.5.2 SBData
The bq78PL116 is designed to the smart battery data system specification, which allows
easy interrogation of data over the SMBus using the commands given in the data sheet for
the chip.
Page
10
3. Description of Results
3.1 The AUV Project
The AUV project has been underway for a number of years at Flinders University, and as a
result, the hardware for the battery management system had already been researched and
designed. Before me, a fellow student, Fabian Craheix, had designed a system which
included the PIC24HJ128GP506A microcontroller, the bq78PL116 master gateway
controller, multiple bq76PL102 fuel gauges and various other components that would,
altogether, create a battery management system. It was my job to write the software for
the PIC, allowing communication between the master gateway controller and the main CPU
of the AUV. This communication was done in two steps. First, the CPU would request
information from the PIC over the CAN bus, the PIC would recognize and acknowledge the
request, and then communicate over SMBus to the bq78PL116. The bq78PL116 would then
collect the requested data, send it back to the PIC over the SMBus, which could then send it
back to the CPU over the CAN bus. However, communication between the PIC and the
bq78PL16 wasn’t limited to only when the CPU requested it; the PIC would periodically
gather the data from the SMBus and store it in flash memory, creating a log of the
charge/discharge history over the lifespan of the batteries
Further requirements of the BMS for the autonomous underwater vehicle were to monitor
battery cell voltages, keeping them between 3.3V and 4.2V, balance cell voltages, monitor
over/under charging, and monitor temperatures of the batteries. The bq78PL116 satisfies
these requirements and is the reason for being selected in the first place. The reason for
keeping the batteries above 3.3V, instead of the cut off voltage of 3V, as mentioned in
section 2.2 Lithium-ion polymer batteries, is because the minimum voltage that the motors
on the AUV require is 3.3V. Also, as was seen in Figure 1, Section 2.2.2, the voltage of a LiPo
drops off considerably fast after 3V, so having a buffer zone above 3V of 0.3V is much safer
and ensures the batteries will never get to a critical voltage point.
The AUV in this project uses 48 batteries arranged into 2 packs of 24 batteries. Each pack of
24 batteries is made up of 12 cells, which means that 2 batteries are connected in parallel
for each cell. This gives the AUV a huge 3kWh powerhouse.
3.2 bq78PL116EVM
Whilst developing the software, I didn’t have a completed battery management system
built, as its design had only just been completed, so I was working with the evaluation
module (EVM). The EVM was like a development board that microcontrollers can often be
used with, and had multiple components already on board, allowing a test battery
management system to be put together. On the EVM board is a single bq78PL116 chip, 6
bq76PL102 chips, SMBus connection, and test points for checking voltages with a
multimeter, so right away it was clear that it would be a very useful tool while developing
the software.
Page
11
3.3 Cell Simulator
A cell simulator was used instead of real batteries as it gave me more control over the
voltages, and also meant that I didn’t have to rely on batteries being charged or discharged
to a certain point. Following the bq78PL116EVM user manual, a cell simulator was
constructed using 12 10Ω resistors in series. Figure 3 shows the cell simulator.
Figure 4: Cell Simulator Circuit (bq78PL116EVM Users Guide, January 2011, page 4)
Using a bench top power supply, banana plugs and header pins I wired up a 12 cell
simulator, and applied a voltage of 54V across the resistors. This gave the recommended
voltage of 4.5V across each individual resistor. When it came to testing the cell simulator
with the EVM bundled software, the 12 cells wouldn’t be recognized, despite agenizing wire
integrity checks and resistor integrity checks. After a time of not being able to figure out
what was going wrong, I tried the test with a cell count of just 8. At first, this also didn’t
work, which became quite frustrating, as there was nothing wrong with the wires nor the
resistors, so the problem seemed to be with the EVM. The breakthrough came one morning
when I decided that I would just give it one more go, before writing the chip off as being
defective. For whatever reason, the software started to communicate correctly with the
EVM, recognizing the 8 cell simulator. It still wouldn’t recognize the 12 cell simulator
however, so I just went ahead with testing using an 8 cell, as it would have been simple to
increase the cell count to 12 before the software is used on the AUV.
Page
12
3.4 bqWizard
bqWizard is the name of the software that is bundled with the EVM as mentioned in the
previous section. The bqWizard consists of a graphical user interface that shows all the data
that the EVM is collecting. The data is collected over a USB-SMBus adapter also developed
by Texas Instruments called the USB-To-GPIO adapter. This adapter is an EVM that will
convert USB commands to SMBus for the bq78PL116 to read, and alternatively convert the
return SMBus commands to USB for the software to read. This software also serves a very
important purpose of creating and programming the configuration file that the
bq78PL116EVM requires, even if the computer software isn’t going to be used for data
monitoring. So once the software had started up, and there was recognition of cells, the
configuration file had to be created which would tell the bq78PL116 chip that there are 8
cells being monitored, as well as other things like which temperature sensors to use, and
how to display the fuel level on the EVM’s LEDs. However, the only important setting is
ensuring that the correct cell count is selected. This configuration file was then saved, and
had to be loaded back into the bqWizard, which would then re-connect with the EVM and
start monitoring all 8 cells. I did try creating a 12 cell configuration file and loading that into
the software, however this didn’t help with recognizing a 12 cell simulator, so I just
continued on with an 8 cell simulator.
3.5 SMBus
Whilst trying to develop the software for the battery management system, a lot of my time
was spent trying to understand the SMBus, and trying to get it to work with the test PIC
microcontroller I was using. I was having quite a lot of trouble in understanding just how I
was supposed to set it up, as there isn’t much example code available that I could find. I
eventually found the right documentation that told me about the required functions of the
SMBus, and using both that and I2C set up help information, I was able to put together some
SMBus functions that could be used by the PIC to communicate with the bq78PL116. Using
the SMBus functions I then created a reasonably simple program that would monitor all the
required variables of the battery cells.
3.6 CAN Bus
I wasn’t able to test out code for the CAN implementation as the PIC microcontroller I was
using for testing didn’t have CAN capability, and I couldn’t get a microcontroller that did
have the capability. As a result, the program that I did write for CAN communication is
theoretical based upon what I’ve read.
Page
13
4. Conclusion
Even though the battery management system was developed for this one autonomous
underwater vehicle using lithium polymer batteries, it can be easily modified to work with
any other AUV, electric vehicle, or robot that uses any type of battery. The only thing that
will need to be changed is the voltage safety limits in the software and the configuration file
for the bq78PL116, if using a different number of cells. So while the battery management
system has been developed for one AUV, it isn’t limited to just this one AUV.
As more and more devices become portable, and batteries become smaller and thinner,
battery management systems become even more important, as a lot of the time, even
though the battery is getting smaller, the power that it can deliver isn’t changing. As battery
development evolves, the devices and components used to monitor them will need to
evolve also, until a battery is developed that can manage itself in any situation it is used in.
Page
14
5. Glossary
SMBus – System Management Bus
CAN Bus – Controller Area Network Bus
Master Device – a device that issues commands and controls the clocking of serial
communications
Slave Device – a device that receives commands from a master device. It doesn’t control the
clock, only responds to clock events.
I2C – Inter-Integrated Circuit
MSB – most significant bit
LSB – least significant bit
CPU – central processing unit
Page
15
6. Acknowledgements
Whilst working on the project I received assistance from multiple people within the Flinders
University team. Craig Peacock helped me greatly with getting SMBus set up, showing me
how to use a logic analyser to view the data that is being sent over the serial line, as well as
helping with general hardware needs, and development board needs.
Andrew Lammas was also very helpful in the beginning, helping me to get the cell simulator
set up correctly, and also checking it for faults.
Most of all Karl Sammut, who allowed me to work on this project, and guided me through
the various requirements of the battery management system.
Page
16
7. References
Applications of Autonomous Underwater Vehicles in Offshore Petroleum Industry
Environmental Effects Monitoring, Utas, http://eprints.utas.edu.au/3340/
Complete Guide to Lithium Polymer Batteries and LiPo Failure Reports, RC Groups,
http://www.rcgroups.com/forums/showthread.php?t=209187
Lithium-Ion And Lithium-Ion-Polymer Batteries, Radioshack Support,
http://support.radioshack.com/support_tutorials/batteries/bt-liion-main.htm
Lithium-ion polymer battery, Wikipedia, http://en.wikipedia.org/wiki/Lithiumion_polymer_battery
Lithium Polymer (LiPo) Battery Guide, Prototalk,
http://prototalk.net/forums/showthread.php?t=22
SMBus, Tech-FAQ, http://www.tech-faq.com/smbus.html
System Management Bus (SMBus) description, SMBus.org,
http://smbus.org/specs/smbdef.htm
Smart Battery Data Specification, SBS Forum, http://sbs-forum.org/specs/sbdat110.pdf
CAN bus Communication Principles, Softing, http://www.softing.com/home/en/industrialautomation/products/can-bus/more-can-bus/communication.php?navanchor=3010115
What is CAN Bus?, CANbus Kit, http://canbuskit.com/what.php
Page
17