Download Battery Water Level Monitoring System

Battery Water Level Monitoring
System
Team Members:
Jonathon Reimer
Joseph Sara
Ryan Estep
Faculty Advisor:
Dr. Rashmi Jha
Industry Sponsor:
Drew Barrett – Flow System Inc.
Presentation Outline
I. Introduction
II. The Battery Monitoring Problem
III. The Battery Water Level Monitoring System
IV. System Architecture
V. Hardware Design
VI. Software Design
VII. Progress Completed
VIII. Future Outlook
IX. Q & A
Introduction
• The Battery Water Level Monitoring System is
a system comprised of both hardware and
software.
• It contains embedded code, database
software, PCB technology, and wireless
transmission.
• We will be outlining all aspects of the system
The Battery Monitoring Problem
• Used in many different solutions – from providing power to
fleets of golf carts to providing storage banks for wind farms
• Their low cost combined with their high current output make
them widely available and widely used.
• The biggest problem, however, is maintenance
The Battery Monitoring Problem
• Lead acid batteries contain a series of plates submerged in a
mixture of water and sulfuric acid
• Over time, water is lost from the recharging process and
evaporation
• As the water level diminishes,
battery efficiency decreases
The Battery Monitoring Problem
• Typically, the water level is monitored by a probe submerged in
the battery cell
– The probe utilizes the voltage of the battery cell.
– When the water reaches a critical level the circuit is broken and the LED
turns off
• Unfortunately, the LED must be monitored by visual inspection,
requiring extra manpower for the
maintenance process
The Battery Water Level Monitoring System
• Our proposed system seeks to streamline the battery
maintenance process.
• By monitoring the battery wirelessly we can eliminate the
visual inspection from the equation
• This eases battery maintenance
The Battery Water Level Monitoring System
The system is comprised of three parts:
1. The Client Node
2. The Server Node
3. The Data Display Module
System Architecture
- The wireless network is
assembled in a mesh network
configuration
- Client route messages though
other Client Nodes
- This extends the range of
individual Client Nodes
System Architecture
- When data transmission is
finished, the network enters
SLEEP MODE
- The Server Node broadcasts a
SLEEP signal to the entire
network
- The Client Nodes enter a low
power state for an allotted
amount of time
System Architecture
• Why Is This Important?
– This system allows a single central user to monitor the
water level of a potentially large number of lead-acid
batteries
– The mesh networking allows each device to use a very
small amount of power while transferring data over a long
distance
– This makes the system useful in a large number of
applications
Constraints and Assumptions
• System should be able to function in outdoor environments
– Appropriate housing must be made for Client Nodes
• Probing lead acid batteries should not compromise
surrounding environment with leaked acid
• The Data Display Module should run on Windows XP/7/8
• PCB board should be as small as possible while still allowing
for the mounting of the FTDI board
• Wireless communication should not interfere with other
wireless systems
Non-Technical Issues
• 2.4 GHz is a busy Wifi frequency
– Due to the low range of individual Client Nodes it is unlikely they will
interfere significantly with Wifi communication
• The signal being detected is simple – logic HI or logic LO. This
means this system could be applied to any number of
applications.
Electrical Design Elements
• The Client and Server nodes use an Atmel
ATMega MCU
• These boards also contain voltage regulators,
crystals, filters, etc.
• One PCB design that can be used as either a
Client or a Server
– Depending on the peripherals attached, the PCB
board can be configured for either functionality
Power Circuit Functionality
Client Node
Client Node
Server Node
– Ultralow dropout voltage regulator used to step
down voltage up to 5.5V and output 3.3 V to
power the MCU
Monitoring Circuit
Client Node Monitoring circuit
• The monitoring circuit is made three parts:
1. A battery probe
•
Creates a conducting path to measure the battery cell’s
associated voltage
2. A voltage regulator
•
Rated to regulate up to 16 VDC
3. A CMOS inverter
•
•
The voltage from the battery cell is regulated to a 1.8 VDC level
to be inverted by the CMOS inverter
1.7 VDC is the threshold between HI and LO
MCU Schematic
CPU Timekeeping Crystal
Antenna And Filter
Antenna Timekeeping Crystal
FTDI USB Interface
• FTDI USB Interface
• the connection of the USB interface, through to FTDI board, to the
microcontroller's input pins
• Connected to the PCB board using through-holes labeled GND, 3.3V, TX in, RX
in, TX out and RX out.
PCB Board Layout and Layers
Antenna And Filter
JTAG Programming Interface
MCU
FTDI Through-hole Interface
Probe Leads
PCB Board Layout and Layers
• The inside layers are devoted
entirely to VCC and GND.
• The outside layers provide the
connections between components
Wireless Transmission
• The Atmel ATMega MCU has a built in Low-Power
2.5 GHz transceiver configured for IEEE 802.15.4
• 2.45 GHz Harmonic Filter-Balun used between
antenna and MCU
– From a balanced to unbalanced 50 Ω microstrip
• A Swivel SMA antenna used to transmit and
receives signals
– with 4.1 dBi (isotropic antenna) gain
– 1.2 voltage standing wave ratio (VSWR)
Client Node Power Analysis
• Under normal operating conditions
𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑛𝑔 𝐿𝑖𝑓𝑒𝑡𝑖𝑚𝑒 = 243.9 Days
• The lower bound on operating time can be
found if 100% operating time
– 𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑛𝑔 𝐿𝑖𝑓𝑒𝑡𝑖𝑚𝑒 𝐴𝑙𝑤𝑎𝑦𝑠 𝑂𝑛 = 6.59 Days
– 𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑛𝑔 𝐿𝑖𝑓𝑒𝑡𝑖𝑚𝑒 𝐴𝑙𝑤𝑎𝑦𝑠 𝑆𝑙𝑒𝑒𝑝 = 243.9
Days
Embedded Software Overview
• Software differentiates the hardware into a Server node
and multiple Client nodes.
– Client nodes measure the water level on each battery
– Server node collects the information and manages the sleep
cycles of the clients
• Uses the Atmel BitCloud framework to implement IEEE
802.15.4 (ZigBee) communication.
• Goal of the software is to reliably retrieve the data from
each node, while keeping power usage to a minimum.
BitCloud Framework
• Designed by Atmel, this framework implements
important features the microcontroller provides.
– ZigBee PRO Certified Communication
– Serial Communication (UART)
– Timers
– GPIO
BitCloud has its own internal task
manager that uses cooperative
multitasking
•
User application is run as a task
within the BitCloud Stack
Network Architecture
• The ZigBee network is organized around a single
Coordinator, and multiple Routers.
– The Server node acts as the ZigBee Coordinator
– The Client node acts as a ZigBee Router
• Each Client has a unique address that the Server
uses to differentiate the Clients.
• The Server is always joined to the ZigBee
network. The Clients join it only for a short time
while sending data.
• Clients out of range of the Server, will route their
information through nearby nodes.
Client Functional Design
• Client software is designed to be
as simple as possible
– On startup or wakeup it attempts
to join the ZigBee network.
– Once it joins the network, it reads
the battery water level, and sends
the data to the server node.
– The client will wait for a sleep
message from the server
– Once the sleep message is
received, the client will disconnect
from the network, and sleep for
the specified time
Server Functional Design
• Server software is designed to
manage the clients.
– It receives all the logging information
from the clients
– Forwards the logging information via
the UART port to the logging
computer.
– When all the clients have reported in,
the server broadcasts a sleep
command to all clients, dictating how
long they should sleep.
– Will send custom sleep times to nodes
that are out of sync.
Data Display Module
• The Data Display Module is designed to
consolidate all the transferred information
– It receives all the logging data from the Server
via the USB port
– It receives this information and stores it in a
SQLite database
– This information is displayed for the user in a
GUI
Data Display Module
• The user has the power to:
– Provide the “Name” and “Description” associated
with each Client in the network
– Choose which serial port to monitor
– Track water level trends on a historic level
– Check on Client Node status in the network
– Monitor Server Node console output
Progress Report
• What Have We Accomplished?
– Currently we have a working prototype (right in front of
you)
– Most of the functionality is completely developed
– The design team is testing and polishing niche
functionality to bring the entire system to an appropriate
acceptance-tested level
Future Outlook
• The final acceptance tests and bug fixes will likely be finished
well under the end-of-semester deadline.
• This leaves documentation as the only significant remaining
hurdle
• A potential Phase 2 prototype has been discussed, with
various improvements made in the design, based on
experience garnered from the prototype you see in front of
you
In Conclusion
• The Battery Water Level Monitoring System serves to
streamline one of the largest hurdles in utilization of leadacid batteries – maintenance
• The three parts of the system divide it into functional
groupings, helping to illustrate how each aspect of the design
works together to satisfy the requirements proposed
• With a working prototype the future looks excellent.
QUESTIONS?