ECE 477 Final Report  Spring 2010
Team 12  A.F.C.I.
Figure 0: Team portrait with completed project (From left to right: Ronny Wijaya, Darin Tanaka, Naman Chopra,
Suan-Aik Yeo)
ECE 477 Final Report
Spring 2010
Team Members:
#1: ____Suan-Aik Yeo____________
Signature: ____________________ Date: _________
#2: ____Naman Chopra___________
Signature: ____________________ Date: _________
#3: ____Ronny Wijaya____________
Signature: ____________________ Date: _________
#4: ____Darin Tanaka____________
Signature: ____________________ Date: _________
CRITERION
SCORE
MPY
Technical content
0 1 2 3 4 5 6 7 8 9 10
3
Design documentation
0 1 2 3 4 5 6 7 8 9 10
3
Technical writing style
0 1 2 3 4 5 6 7 8 9 10
2
Contributions
0 1 2 3 4 5 6 7 8 9 10
1
Editing
0 1 2 3 4 5 6 7 8 9 10
1
Comments:
TOTAL
TABLE OF CONTENTS
-ii-
PTS
ECE 477 Final Report
Spring 2010
Abstract
1
1.0 Project Overview and Block Diagram
1
2.0 Team Success Criteria and Fulfillment
3
3.0 Constraint Analysis and Component Selection
3
4.0 Patent Liability Analysis
8
5.0 Reliability and Safety Analysis
11
6.0 Ethical and Environmental Impact Analysis
15
7.0 Packaging Design Considerations
19
8.0 Schematic Design Considerations
21
9.0 PCB Layout Design Considerations
26
10.0 Software Design Considerations
30
11.0 Version 2 Changes
37
12.0 Summary and Conclusions
38
13.0 References
38
Appendix A: Individual Contributions
A-1
Appendix B: Packaging
B-1
Appendix C: Schematic
C-1
Appendix D: PCB Layout Top and Bottom Copper
D-1
Appendix E: Parts List Spreadsheet
E-1
Appendix F: FMECA Worksheet
F-1
-iii-
ECE 477 Final Report
Spring 2010
Abstract
The purpose of this project was to provide instrumentation for a hydrogen powered vehicle that
would allow a user to easily analyze the hydrogen system. The primary goal was to aid in the
research of promising hydrogen –fuel technology that Professor Jerry Woodall is developing.
Naman Chopra provided the vision of this project as he is currently working under him.
1.0 Project Overview and Block Diagram
Figure 1-1: Photograph of Completed Project
1
ECE 477 Final Report
Spring 2010
Figure 1-2: Block Diagram
The AFCI (Alumoline Fuel-Cell Instrumentation) system is an instrumentation and analysis
system for a hydrogen powered golf cart. This golf cart will consist of a hydrogen internal
combustion engine, in which a water tank will supply water to a hydrogen tank which contains
liquid gallium saturated with aluminum, more information about this research can be found here.
This system will provide an easy-to-use user configurable display to monitor sensor data. The
data that will be monitored will be: hydrogen tank temperature, hydrogen tank pressure, water
tank temperature, water tank pressure, and hydrogen tank leakage. A touch screen interface will
be mounted onto the golf cart to allow the driver to easily monitor sensor data. This data can be
display in terms of a meter panel or the user may opt to see the data in a real time data versus
time scatter plot. Also the user may only want to view one or two sensor values at a time. Our
system will allow different panel displays in a one-meter mode or two-meter mode. Another
important feature the AFCI implements is the logging of data. The user will be able to log
specific sensor data values onto an external media (SD card) which will have time specific
stamps associated with it. Along with this functionality the user can also change how often data
2
ECE 477 Final Report
Spring 2010
will be logged to the SD card. We are hoping that this project will aid in the research for
Professor Woodall.
2.0 Team Success Criteria and Fulfillment
PSSC
Preliminary
Final
An ability to receive and correctly record values
Fulfilled
Fulfilled
Fulfilled
Fulfilled
An ability to store data on external memory.
Fulfilled
Fulfilled
An ability to use a touch screen to send
Fulfilled
Fulfilled
Fulfilled
Fulfilled
from various sensors.
An ability to give appropriate warnings and
troubleshooting instructions if a sensor detects
something wrong.
commands to the microcontroller to control the
logging of data and to provide a user
configurable display for the logging of data from
multiple sensors.
An ability for the microcontroller to receive and
execute commands to remotely enable, disable
and control the sampling rate of multiple
sensors.
Table 2.1: PSSC Fulfillment
3.0 Constraint Analysis and Component Selection
3.1 Design Constraint Analysis
A number of design constraints need consideration. The device must be durable as the golf kart it
will be mounted on will experience moderate speeds and large forces. So strong packaging is of
high-priority. That’s why we will use hard military-grade aluminum project enclosure.
3.1.1 Computation Requirements
Overall we do not have very stringent computation requirements for the system. Mainly, our
micro-controller will need to gather, interpret and send sensor readings to the Atom Board at a
3
ECE 477 Final Report
Spring 2010
speed of 2 readings per second. Although this is a multi-step process which consists of the
microcontroller getting interrupted by the timer, performing analog-to-digital conversion on the
sensor data, creating and sending the corresponding message to the Atom board over SCI. All
this can be easily achieved by the 9S12C microcontroller.
Apart from that, our Atom board will have to have enough computation power to provide a
responsive fully-graphical 1024x768 user interface, while interpreting touch-screen user
feedback at the same time. This is not a problem as it is a full-blown computer motherboard,
complete with integrated graphics, and is more than capable of providing a responsive user
interface.
Finally, our microcontroller will need to be able to write the sensor data logs to the SD card at a
sufficiently quick rate so that the user will not have to wait for the data to be saved. According to
Suan's previous experience working with interfacing SD technology directly over SPI using the
9S12C, this can be easily achieved.
3.1.2 Interface Requirements
The only general-purpose I/O pin that we might use is a “powered now” red LED indicator. We
are using 5 sensors and each will be connected to a pin with ATD capability for a total of 5 pins.
Currently, we do not see a need for optical isolation in our circuit.
3.1.3 On-Chip Peripheral Requirements
Primarily for this project we will be making heavy use of our ATD channels in order to convert
analog sensor data into digital values we can compute. We will need six ATD channels in total.
One pressure, temperature, and water level sensor will be needed for both the hydrogen fuel tank
and the water tank. We will also need a channel for an SCI (RS-232 serial) in order to
communicate with our Intel Atom board. This SCI will be heavily used as all information about
the sensors needs to be sent to the Atom Board periodically. Lastly we will need SPI to
write/read to an external SD card. The Atom board will control the reads/writes to this SD card
although the microcontroller will be the one actually implementing this.
3.1.4 Off-Chip Peripheral Requirements
For this project we will need a number of off-chip peripherals. One of the peripherals we will
need will be a SD card reader module. This SD card reader module will be used to save logs of
our sensor data in order to satisfy our PSSC. Another peripheral we will need is an Intel Atom
board. We are going with the PCM-9361 from Advantech. Since we are going to create a
4
ECE 477 Final Report
Spring 2010
graphical user interface (GUI), we need an operating system to implement graphical libraries.
The Atom board will constantly be communicating with the microcontroller to retrieve sensor
information and also to inform the microcontroller to save sensor data to the SD card. The LCD
touch screen is another peripheral we will need. We decided to get the 7 inch touch screen from
Xenarc. This will be connected to the Intel Atom board and will display the GUI. When a user
invokes a certain feature on the touchscreen, the information will be sent to the microcontroller.
The only purpose for the Atom board and LCD is to support the GUI. Lastly we will need
sensors to measure all of our data. For the temperature sensor we will be using a thermocouple,
kqss-116u-18, from Omega. For the pressure we will be using the P1200 pressure transducer
from GE. We will also have a hydrogen leak detector sensor from Figaro. It will be mounted
under the seats of the car, close to the internal combustion engine or fuel cell (depending on the
vehicle it is mounted on).
3.1.5 Power Constraints
Originally we planned to power our system straight from the 48V battery that the golf cart uses.
However, after a discussion with Chuck this week and some further analysis we decided to add a
dedicated 12V battery whose sole purpose is to power our system. The two main factors were
because the Atom board is a significant power draw and could affect the normal operation of the
golf cart; and we did not want the entire system to undergo a sudden power-off when the ignition
is turned off, especially since any SD card transactions taking place at that time could corrupt the
filesystem on the card. We decided on a 12V battery because most components in our system
(including the atom board) with the exception of the microcontroller and the SD card reader
module can be powered by 12V. The microcontroller needs a 5V power source and the SD card
reader needs a 3.3V. Our entire system is DC-powered. The only foreseen heat-dissipation issue
is the Atom board, which could be dissipating heat into the dashboard which is an enclosed
space, leading to increasing heat-up of the system.
3.1.6 Packaging Constraints
The PCB needs to withstand vibrations and outside temperature (below 0 C). The team won't be
around for repairs so the system needs to be durable.
3.1.7 Cost Constraints
The total cost of the complete instrumentation project should not exceed $1000.00. We have
funding from Professor Woodall but we still have to keep the costs reasonable. There are
commercially available systems which can easily monitor this type of system but they are not
5
ECE 477 Final Report
Spring 2010
mobile and compact like ours. Plus they tend to be quite expensive and don’t display all the
information on one compact display.
3.2 Component Selection Rationale
Atom Board
Although we could technically use the Atom board provided in lab free of charge, we needed to
buy our own because we wanted the finished project to persist past the end of the semester and
did not want to return it. The PCM-9361 is the cheapest Atom Board Suan found that fit our
requirements (VGA and integrated graphics support, small form-factor for easy placement into
the car dashboard, fanless operation to reduce mechanical complexity and moving parts, compact
flash support to remove the need for a larger hard drive). On top of being cheaper than the labprovided IB-887 board, it has the convenience of having a standard 9-pin serial port.
PCM-9361 (selected)
IB-887
VGA interface and port
yes
yes
Serial interface
yes
yes
Standard 9-pin Serial RS-232 connector port
yes
no
Compact Flash ready
yes
yes
Area
3.5"
3.5"
yes
Onboard graphics
Price
$263
yes
$344
Table 3.2-1: Atom board comparison
LCD
These were the two primary touch-screens we were looking at. Both of these had VGA inputs
along with USB touch-screen outputs. The prices for both of these were about the same if you
include shipping. In the end we decided to go with the Shark because it had a better resolution
along with the fact that it can operate at a lower voltage.
6
ECE 477 Final Report
Spring 2010
Armatexx 7 inch touchscreen
Shark 7 inch touchscreen
Resolution
800x480
1024x768
VGA
Yes
Yes
Voltage required
12 Volts
10.8 Volts
Dimension
179 x 29 x 122 mm
180 x 25 x 125 mm
Price
$139.81
$129.99
Table 3.2-2: LCD comparison
Microcontroller
When we were choosing the microcontroller, we put our priority on its capability on getting the
signal from the sensors easily which means it had to have enough ATD channels to ease up the
process, also its peripheral features to communicate with the SD card and the Atom board, and
its programming environment. An operating voltage of 5V would be ideal as many of our
sensors’ output range is up to 5V. A clock speed of about 8MHz would also be good enough for
our purposes. Having these points in mind, we searched many microcontrollers on the internet.
We came up with these two choices: Atmel AVR ATMEGA16 and Freescale 9S12C32.
ATMEGA16 [1]
Freescale 9S12C32 [2]
ATD Channel
One 8-channel 10-bit
One 8-channel 10-bit
SD Card interface
One synchronous SPI
One Master/Slave SPI
Atom board interface
Programmable USART
One asynchronous SCI
Online Support
AVRFreaks.net
Freescale.com
Flash
16 kb
32 kb
RAM
2 kb
2 kb
Table 3.2-3: Microcontroller comparison
We had our thoughts between these two choices and came up with Freescale micro-controller.
We all had considerable experience with interfacing this micro-controller so that would
accelerate our development process. On the flip side, we can't use the great support on the
AVRFreaks.net and AVR's USART feature but that would be fine as we had a great support as
well from the senior design staff.
7
ECE 477 Final Report
Spring 2010
3.3 Summary
The A.F.C.I is subject to a number of design constraints, the most important being the product
needs to last years as it will be used to aid the research process. The system should be of low
power consumption. Based on the requirements, a microcontroller, an atom board, an LCD, and
sensors were chosen appropriately.
4.0 Patent Liability Analysis
4.1 Introduction
The AFCI system will be used to provide an easy to use monitoring capability to the driver of a
hydrogen powered golf cart. This system was built in order to aid in the research of Professor
Woodall, who is currently working on hydrogen powered vehicles. There will be a touch screen
interface in which the driver may control the system in an easy to use interactive graphical user
interface; this type of implementation is different than current hydrogen monitoring systems
where generally a remote system will be monitoring the vehicle. The AFCI system will monitor
hydrogen tank temperature, hydrogen tank pressure, water tank temperature, water tank pressure,
and hydrogen tank leakage. These values will be displayed to the user as 5 meters. The user will
also have the option to view a graph starting from the current time by clicking one of these
meters. Also the user will have the option to store sensor data onto an SD, and also will have the
option to customize which data gets stored onto the SD card. This SD card feature is not
available in other hydrogen monitoring systems. In order to measure the temperatures we are
using K-type thermocouples. For pressure, we are using amplified pressure transducers. Lastly
for the hydrogen leak detection, we are using a pre-calibrated module for gas leak detection. The
system will be implemented using a micro controller and an Intel Atom board. The micro
controller will be primarily responsible for reading the ATD values, sending them to the Atom
board, and logging data to an SD card. The Atom – Board will be solely responsible for
managing the graphical user interface and configuring the microcontroller. The Atom board and
micro controller will communicate via the UART scheme.
4.2 Results of Patent and Product Search
There were a few existing patents that dealt with golf cart touch screens or a hydrogen
monitoring system for a vehicle. Our system has two primary functions, which is an ability to
provide a touch screen interface on a golf cart, and an ability to monitor the pressure,
temperature, and hydrogen leaks on a hydrogen powered vehicle. The following sections will
discuss three patents that were found which could cause a patent liability.
8
ECE 477 Final Report
Spring 2010
The first patent that was researched is called “Golf course management system for golf carts”,
with patent number 20090201263. This patent was filed on 2/09/2009. The abstract of the patent
describes a touch screen display connected to a “processor” which includes a GPS to determine
locations of the golf cart. The touch screen will be used to display data and also be used to send
calculation data to the “processor”. The processor will be used to calculate touch positions and
coordinate positions. Also the processor will be used to display golf course tees onto the touch
screen.
The second patent that was researched is called “Methods for Monitoring Hydrogen Fueling
Systems”, with patent number 20090297897. This patent was filed on 12/05/2008. The abstract
describes this apparatus to provide a hydrogen leak detection mechanism. An event controller
will measure pressure of the hydrogen gas before, during and after fueling operation. If certain
pressure thresholds are exceeded the hydrogen fueling system will be shut down. A compressor
will be used in order to regulate pressure. The so called “event controller” will be a
programmable logic controller. To be more specific one of the claims is a decrease of 100 psig
will result in a hydrogen fueling shutdown.
The third patent that was researched is called “Computer System and Method for Monitoring
Hydrogen Vehicles”, with patent number 20080234888. This patent was filed on 12/01/2005.
The patent abstract describes a system in which it remotely monitors a hydrogen vehicle. This
system includes a data acquisition/communication module configured to receive signals which
represent status conditions associated with the vehicle. A computer will be used as a remote to
control this hydrogen monitoring system. The display will be located on the hydrogen powered
vehicle. The status conditions mentioned earlier contains many different types of data. The ones
most relevant to our project is hydrogen tank pressure and hydrogen tank temperature.
4.3 Analysis of Patent Liability
Although the patents listed above have many similar features of the AFCI system there are no
literal infringements we need to worry about. The golf cart system that was described above
calculates completely different data and is used an entirely different context. Also for the
“Monitoring Hydrogen Fueling Systems” they’re method of calculating hydrogen leak detection
is based on multiple pressure checks. The AFCI system on the other hand detects hydrogen leaks
through a commercial pre calibrated module in which it provides a voltage reading based on the
gas concentration levels. In the claim, the monitoring hydrogen fueling system is patenting the
9
ECE 477 Final Report
Spring 2010
method of calculating hydrogen leak detection not the electrical method of detection on a
hydrogen vehicle. There may be a doctrine of equivalence regarding the “Computer System and
Method for Monitoring Hydrogen Vehicles” patent. The AFCI system also uses a
communication module which really is our micro controller. Also we use this module to measure
“status” data such as hydrogen tank temperature and pressure. Similarly as well, the AFCI
system will use a computer, our Atom board, to control the hydrogen monitoring system.
Although a lot of functionality is similar our design defers from this patent because we are using
an SCI protocol to communicate with the host computer and communication module.
Specifically the remote system will be off the vehicle, where as our system will be entirely on the
vehicle.
4.4 Action Recommended
The highest potential for infringement is with regarding to the “Computer System and Method
for Monitoring Hydrogen Vehicles”. However if we were ever to get into a liability issue, an
argument we could use is that our remote implements a touch screen interface where as their
system distributes data as a web server. So although we both provide substantially the same
function the implementation is in a relatively different way. Also there could be a potential
liability with the golf cart touch screen system. Both of our systems bring the idea of having a
touch screen interface mounted on top of a golf cart. The argument we would bring up for this is
that, although our golf cart setup are similar our functionality is different. The golf cart system is
using GPS in order to calculate coordinate on a golf course, but our system is monitoring a
hydrogen vehicle. Using this argument we can avoid doctrine of equivalence.
4.5 Summary
There were three patents that were analyzed regarding if our project had a possibility of
infringement. All three of these patents had similar component or design mechanism as the
AFCI system. However none of these patents create a literal infringement liability with our
design. Also there are no clear cut doctrines of equivalents as all the differences can be seen.
Differences such as a golf cart GPS and a hydrogen monitoring system. Also a difference like
having a remote system compared to a on board system. Overall we believe that the patent
liability of our design is very low.
10
ECE 477 Final Report
Spring 2010
5.0 Reliability and Safety Analysis
5.1 Introduction
AFCI was a monitoring device that is designed for a Hydrogen Fuel-Cell electric vehicle. This
product was made for the researchers’ group that develops this specific vehicle. Since this device
would be used by the research team heavily, we considered the safety and the reliability issues so
the system would work without making any inconvenience for the users. For safety issues, our
system had to keep itself from messing up the vehicle's system. Aside from that, we would like
to keep our battery safe from short circuit. On the reliability side, our system would bring a
dependable performance with the needed sensing accuracy.
5.2 Reliability Analysis
Among the components in our system, we believed that there were several components that were
more likely to fail than the others. We carefully selected the components that would give us the
longest lifetime span for our system.
The first component was the battery which was our main power source. This battery brought 36
Volts and if the positive and the negative connection were shorted, a big spark would occur. On
the reliability issue, the battery had a certain lifetime which may need users to take actions on it.
The second component was the power regulator which was responsible to regulate from our main
power source's voltage (36 Volts) to a stable 12 Volts. The component, which was named
VKP100MT312C, was pretty big and complex that it generated heat when it operates for a long
enough time duration. The heat generated could damage itself and make it unreliable for
operation. If this component failed, it could do some damage since high voltages would be
forwarded to the sensitive Integrated Circuits.
The third component was the amplifier Integrated Circuit (IC) that we used. This IC was for
translating the cold junction technology of the thermocouple used by the system into an analog
signal. Since the accuracy of the sensors depended on the condition of the sensors, the
connection of the sensors and the condition of this ICs as well, we felt that it was necessary to
include this IC into the analysis.
The fourth component was the microcontroller we used. This micro-controller was the most
complicated IC on our Printed Circuit Board (PCB). There was a chance that this device would
11
ECE 477 Final Report
Spring 2010
heat up as it was used. The synchronization between the micro-controller and the other interfaces
may affect the reliability of the whole system.
The other components in our system that might fail were the Atom board and the touch screen
display. Since both of them were commercial products, we expected them to be reliable in a
certain extent. Still, we had to consider steps to make them as reliable as it was promised.
Provided below were the tables of our analysis about the mentioned components' number of
failures per 1x106 hours and their Mean Time to Failure (MTTF).
For the micro-controller:
Parameter name
Description
Value
Comments
C1
Die complexity
0.28
16 Bit
πT
Temperature coeff.
1.5
Assuming 45o F
C2
Pins constant number
0.013
36 used pins
πE
Environmental coeff.
3
Ground, mobile
πL
Learning coefficient
1
> 2 years
πQ
Quality coefficient
5
Estimation for commercial
Entire design:
Micro-controller
2.295
Failures per 1E6 hours
MTTF
49
Mean Time to Fail (years)
Table 5.2-1: Failure analysis for microcontroller
For the 36 to 12 Volts regulator:
Parameter name
Description
Value
Comments
λb
Base failure prob.
0.002
Voltage regulator
πT
Temperature coeff.
1.5
Assuming 45o F
πS
Stress coeff.
1
Big regulator
πC
Construction factor
1
Solid connection
πQ
Quality coefficient
5.5
Mixed material
Entire design:
Voltage regulator
0.0165
Failures per 1E6 hours
MTTF
6 844
Mean Time to Fail (years)
Table 5.2-2: Failure analysis for 36-12V regulator
12
ECE 477 Final Report
Spring 2010
For the cold junction signal amplifier:
Parameter name
Description
Value
Comments
C1
Die complexity
0.02
Simple IC
πT
Temperature coeff.
1.5
Assuming 45o F
C2
Pins constant number
0.048
14 used pins in DIP package
πE
Environmental coeff.
3
Ground, mobile
πL
Learning coefficient
1
> 2 years
πQ
Quality coefficient
5
Estimation for commercial
Entire design:
Thermocouple IC
0.87
Failures per 1E6 hours
MTTF
132
Mean Time to Fail (years)
Table 5.2-3: Failure analysis for cold junction signal amplifier
Based on these calculations, the component that was most likely to fail was our micro-controller.
This was expected as it was the most complex IC we had. We thought of ways to mitigate the
reliability of the system and we came up with several steps. They were:
- Provide enough heat sink for the voltage regulator
- Protec the sensors’ connection by using protective sensor wires
- Provide enough power to the system
- Operate in the approved operating condition
Parts other than the RS-232 driver IC, micro-controller, Atom board, touch screen display and
the sensors would not really make the system totally dysfunctional when they fail. Hence, it was
required that we make sure those components worked as needed for our system to be usable.
5.3 Failure Mode, Effects, and Criticality Analysis (FMECA)
We had five blocks of circuitry when we divide the circuit according their functionality. They
were the power management block, the micro-controller block, the sensors block, the SD card
block and the RS-232 block. Starting with the power management block, it contained all of our
power regulators and the circuitry to support them. These power regulators could overheat as
they were used. This heat could reach a level where it damage the regulators and make them
unreliable. When one of these regulators fails, undetermined voltage output would come to the
voltage rails and it might damage the other ICs as well.
13
ECE 477 Final Report
Spring 2010
On the other block, which was the micro-controller block, we had the micro-controller, the
bypass capacitors, the oscillator and the Background Debugging Mode (BDM) pins. The microcontroller, which was the most complex IC on our PCB, was likely to fail due to heat, soldering
condition and excessive input current. Another possibility was that the oscillator circuitry did not
work so that the micro-controller froze. If the micro-controller failed, our system would not be
able to take the sensors input at all, which could make our system unusable.
The third block was the sensors block. This block contains all the sensors used on the vehicle’s
system and the IC that translated the Cold Junction thermocouple output into familiar analog
signals. Unfortunately, the translator ICs were vulnerable to noises. As a result from the noises
from the PCB, the translator ICs did not give us a very accurate reading.
The fourth block was the SD card block. This block includes the SD card module and the level
translator IC that converts 5 volts signals into 3.3 volts signals. The SD card module was a break
out connection board module we bought from a certain provider. We assumed that this module
was connected properly so it would be reliable enough for our project. The level translator was a
small IC that was prone for pins bridging when we soldered it. If the 5 volts pins and the 3.3
volts pins were shorted, both rails would have 5 volts on them and it might prevent the system to
write data into the SD card, not to mention it might damage the SD card. Another failure that
could happen was the synchronization error. When the SD card could not communicate at the
same pace as the micro-controller’s SPI did, the writing process might fail.
The last block was the RS-232 block. This block contained only the RS-232 driver IC. This IC
was responsible for converting the SCI signals into the RS-232 signals that could be recognized
by the Atom board. Again, a scenario that might fail this block’s main function was the failure
on the synchronization between the micro-controller’s SCI and the Atom board’s RS-232.
Another issue was when this driver IC heated up and failed itself.
Various types of failures may also occur when pins which were supposed to be open were
shorted. This might bring down the voltage down to a certain unpredictable level. If ICs take
insufficient voltage input, they might not work as expected.
To create the same understanding of the criticality of these failures, we defined three levels of
criticality. The first one was low criticality. The failures that belonged to this group were the
ones that both did not remove the system’s ability to monitor the physical properties of the
14
ECE 477 Final Report
Spring 2010
vehicle and did not cause any injury the users. The second one was the medium criticality. The
failures that belonged to this group were the ones that removed the system’s monitoring ability
but did not injure the users. The third one was the high criticality. The failures that belonged to
this group were the ones that both removed the monitoring ability or injured the users in any
way.
5.4 Summary
Our project had two safety constraints that must be followed. The first one was to make sure that
the polarities of the battery did not get shorted. The second one was to keep our sensors or any
other component from messing up the reactor.
We had more reliability issues that had to be considered. These include the performance of our
power regulators, the accuracy of our sensors, the condition of the micro-controller and the usage
correctness of the SD card circuitry and the RS-232 circuitry.
When we have solid software, solid PCB’s connection and correct usage, these reliability issues
should be mitigated.
6.0 Ethical and Environmental Impact Analysis
6.1 Introduction
We are designing an instrumentation and analysis system for a hydrogen-powered golf cart. Its
primary goal is to aid in the research of a very promising hydrogen-fuel technology that Naman
Chopra and Purdue professor Jerry Woodall are developing. The specific values we are
monitoring are the pressure and temperature in the hydrogen reactor and water tank, along with
the hydrogen level just outside the tank, to detect hydrogen leaks.
Our main goal in senior design was to create a functional product. This, combined with the
course requirements, time, budget, and equipment limitations placed on our team, definitely led
to a sub-optimal product in terms of ethical and environmental impact. Two of the main issues
were lack of time and capacity to perform proper testing and excess use of parts and materials.
15
ECE 477 Final Report
Spring 2010
6.2 Ethical Impact Analysis
We are confident that our product works under normal operating conditions where the
temperature is mild and the golf cart is moving slowly on relatively smooth terrain. However,
our product should also be tested under worst case conditions such as in harsh weather and on
bumpy terrain. It becomes an ethical issue when we claim that our product will perform
accurately for an extended period of time and that it is safe to operate, whereas we have not
performed the required testing to give that assurance.
Many aspects of our design are impacted by this issue. Because our product might be used in a
golf cart outdoors, it could be subject to harsh weather and temperature conditions. Our Atom
board is only rated to operate between 0 °C and 60 °C, so we do not know the consequences of
using our product outdoors in the peak of an Indiana winter.
Furthermore, our system could be used on a golf cart while driving on bumpy terrain. We need to
make sure that our connections and fixtures are as firm as possible to ensure optimum safety.
To address these issues, we should include full disclosure of all our doubts about our design.
This is the ethical thing to do even though it will make our product appear less attractive. These
warnings should appear at all places: in product manuals, on stickers on the enclosures, and even
during marketing of the product. To address the very important issue of our system not detecting
excessive pressure buildup in the hydrogen reactor, we have also placed a failsafe mechanical
valve that will pop open in such an event.
Another ethical issue with our design is that because one of our parts is a computer motherboard
with a full-fledged operating system (Ubuntu 9.10) installed, if somebody malicious to the end
user manages to connect a keyboard to the system there are many actions he could do that would
harm the actual user, such as manipulating sensor readings and disabling components. One of the
reasons that we chose to use a Linux operating system was to alleviate this issue since Linux
requires root access to perform significant changes to the system.
16
ECE 477 Final Report
Spring 2010
6.3 Environmental Impact Analysis
Manufacture:
One fact that sticks out about our project is that it uses many more parts than it actually needs.
First of all, our PCB is quite large (8.62”x5.13”) but yet quite sparse.
Furthermore, there is a good possibility that our project doesn’t even need a separate PCB as
most of the functionality can be achieved by the Atom board. By simply attaching an SD card
reader and using some of the Atom board’s general purpose I/O pins for ATD functionality, the
only other part that would be needed is a 12V-5V switching regulator to power the board from
the 12V golf cart battery.
If we determined that we still need a PCB, we could reduce the manufacturing environmental
impact by using lead-free solder.
During Normal use:
Due to large power consumption, there is some amount of heat emitted by our 33-75V to 12V
regulator and Atom board. Compared to most other motherboards out there, our Atom board is
fairly cool and lightweight. It measures 5.7” x 4”, whereas a typical PC motherboard measures
around 12” x 9.6”. We have used a net-like front panel on our enclosure to provide ventilation
for the Atom board. To reduce the environmental impact during normal use we could put our
Atom board and microcontroller in sleep mode when they are idle. We could also reduce the
amount of unneeded background processes running on the Atom board.
During Disposal/recycling:
Because our PCB contains large amounts of lead solder, disposing of it will be quite harmful to
the environment. This could be mitigated somewhat by using lead-free solder. Apart from that,
the 36V lead acid battery we use contains lead and other harmful chemicals such as sulfuric acid.
It also carries a risk of explosion or big sparks if its leads are shorted together, possibly resulting
in a fire. We will place warning labels on the battery to warn of this danger. Finally, although
aluminum is not considered to be directly harmful to the environment, it takes a very long time to
decompose and would occupy landfill space for a long time. As such, during disposal, our
aluminum project enclosure should be recycled instead of just thrown away.
17
ECE 477 Final Report
Spring 2010
Recycling would be the best way to curb the environmental impact of our product – the hard part
is persuading users to recycle the product after they are done with it. If we had a small product
(like a smartphone for example) it would be easy to include a bag with paid shipping labels
attached so that customers could mail it back to us for recycling. Alas, our product is enclosed in
a large aluminum box and includes a sizable lead acid battery so the costs and effort involved in
such a scheme make it impractical.
Fortunately, according to US laws and regulations, in many states [3] it is illegal to knowingly
dispose of batteries in the trash. In most states, the Environmental Protection Agency also
requires retailers that sell lead-acid batteries to collect used batteries for recycling [2]. These
measures should persuade most people to drop off their used lead-acid batteries to a nearby
retailer for recycling.
To prevent our project box and the parts inside to go to waste, we could advertise the fact that
there is actually a full-fledged PC motherboard in the casing. Therefore, after a user no longer
wishes to use our product, the user could contact us and we would provide the root password for
the installed Operating System. That way they could connect a keyboard to the machine and just
use it as a PC.
6.4 Summary
This report outlined and elaborated on the ethical and environmental challenges related to the
AFCI project and how we plan to address them. The main ethical issues we encountered were
lack of testing and security issues related to having a computer motherboard as part of the
product. To address those we plan to provide full disclosure about the caveats of the product and
to use a secure underlying operating system. The main environmental issue encountered is our
project is that it is unnecessarily wasteful. If we were to mass-manufacture our product we will
be able to get by using much fewer components.
18
ECE 477 Final Report
Spring 2010
7.0 Packaging Design Considerations
7.1 Introduction
The packaging, as briefly explained to some extent in the design constraints portion will
basically consist of a box with connectors. This module will be screwed onto the dashboard
beside the LCD. The LCD will also be mounted with its own provided mount which can be
rotated for better view. The box will have an SD card slot on the right side and the user can reach
it easily while sitting in the cockpit. Everything will be controlled from the touch-screen.
The box needs to be sturdy and durable. The sensors will be connected to the reactor vessel and
there will two Ethernet cables connecting the sensors to the box.
7.2 Commercial Product Packaging
Product #1
Nissan GT-R in-dash informational display – The Nissan GT-R is a high performance sports car
(480HP). This was my primary inspiration for designing our A.F.C.I.
The drive computer, as they call it, is developed by polyphonic studios collaborated with Nissan
Japan. There is preset information and also driver selectable information gauges. There is a
gauge for everything - acceleration in G’s, percentage of accelerator pedal pressed, boost gauge,
braking G’s, fuel range, engine oil temp and pressure, transmission oil pressure and temperature
and a ton more things.
The packaging is in-dash housed, not movable, and the microcontrollers are hidden away from
the user’s view. We will have a similar touchscreen display.
We will be monitoring temperature, pressure and leaks. The system we are monitoring is entirely
different from this vehicle. This is a gasoline powered sports car.
19
ECE 477 Final Report
Spring 2010
Product #2
Toyota Prius in-dash informational display – The Toyota Prius hybrid drive computer is not as
fancy as the Nissan GT-R’s but still provide efficiency, fuel range, and temperature readings. It
gives a complete status of the Hybrid Synergy Drive (HSD) technology developed by Toyota;
informing the current state of the system to the driver to help him/her achieve more mileage from
the vehicle.
The display is not touch-screen, there are buttons on both sides of the LCD to view and change
settings. The display again is not movable and is housed inside.
What we will incorporate from this system is the idea of providing an overall state of the system.
We will give appropriate warnings if a sensor exceeds predefined thresholds.
7.3 Project Packaging Specifications
The packaging which we plan to use will be Military grade aluminum metal case which will
enclose the atom board (reminder, this is not the board provided by Purdue, we got our own) and
the PCB in one box. There will be detachable connectors for sensor wires and LCD connection
(VGA and USB) and the box will be designed to open only by screws (4 screws). We would
need a drill for drilling holes for the box which will contain the PCB and the atom board.
The LCD will require some drilling. The estimated weight of the box will be no more than four
pounds. The LCD weights two pounds. The box will be connected through wires that will run
underneath the vehicle’s carpet/mat and will be sealed for water proofing.
The box should not cost more than $50.
20
ECE 477 Final Report
Spring 2010
7.4 PCB Footprint Layout
In placing the components on the PCB, the biggest consideration would be whether we have
enough space for the traces and the header ports. Most of the board’s estate would be occupied
by the serial port, header ports, traces and the electrical circuitry for the power management.
With the total area for those elements and extra area for some trace routing, the estimated
dimension for our PCB would be six centimeters by ten centimeters.
7.5 Summary
Our device will be one of a kind product out there; there is really nothing in the market which
actually measures an Alumoline fuel storage and delivery system. This product will set a
standard in this market for Alumoline monitoring as this is the first prototype ever. The display
GUI will somewhat be a hybrid of the display Nissan GT-R and Toyota Prius, however it will
display information which is entirely different. Our display is flexibly mounted and we can
change direction. It will be placed right behind the steering. The case which houses the atom
board and PCB will be located near the LCD and the user will have access to the SD card slot.
The dimensions are approximated and are written in appendices.
8.0 Schematic Design Considerations
8.1 Introduction
AFCI was an instrumentation device that was designed for a Hydrogen Fuel-Cell electric vehicle.
The main consumer of this product would be the researcher group that developed this specific
vehicle. Hoping that the product would provide the practical advantages to accelerate the
research, we decided to create an instrumentation system that is focused in monitoring the
important physical properties of the vehicle's vital devices as well as giving the ease and the
elegance of using the instrument over a user-friendly interface.
In achieving the functional and interface related goal of this project, we divided the system into
three main parts. They were the Atom board, the sensors to monitor the properties and the
Printed Circuit Board (PCB) which had the microcontroller and its related interfaces. For the
Atom board, we already had a product that we could use right away. We were planning to use
this board to organize the touch display interface which would be the main interface of this
device to the users. In this chapter we would go through the theory of the operation of the three
groups in more details.
21
ECE 477 Final Report
Spring 2010
8.2 Theory of Operation
Starting with the Atom board, we decided to use an Atom board to help us in managing the
graphical user interface. The main reason for choosing an Atom board over a microcontroller to
drive the touch sensing display was to accelerate the development and to simplify the interface
system. When we picked our Atom board, we wanted to choose an Atom board that provided
enough interfaces for the touch sensing display, the communication between itself and the
microcontroller, as well as the development tools which include a flash card slot, a keyboard and
a mouse. Since the Atom board itself had a simple desktop architecture, we could simply take it
as a desktop machine where an Ubuntu Linux operating system could be installed and did a lot of
graphical application. The main storage device for this Atom board would be a Compact Flash
card. Through this card, the Atom board would be able to load the operating system as well.
The second major group of our system was the sensors group. With the consideration that the
environment where we were monitoring was really reactive, we have taken many steps to
comply with the safety conditions of the particular Hydrogen fuel cell we were monitoring. This
fuel cell did not really open up the opportunity for us to use a variety of sensors. The sensors
which could fit this mechanical feature of the fuel cell required a special fitting that most of the
sensors did not have. These sensors would be communicating to the microcontroller through an
Analog To Digital (ATD) interface. One of the thermocouples required an external Integrated
Circuit to drive the ATD signals. We would put it onto our PCB which would explained on the
next paragraph.
The third major part of the whole system was the printed circuit board. The major subsections of
the printed circuit board were the microcontroller, the sensor header pins, the SD card module,
the RS-232 communication port, the power circuitry and the debugging header pins. Starting
from the power, we wanted to have a regulated 5 Volts input for the microcontroller and the
Atom board as well as 12 Volts input for the display and one of our sensors. Since the closest
major power supply provided on the implemented vehicle is a 48 Volts battery, we decided to
use that combined with regulating electrical circuitry to power our system. Considering that the
Atom board used a different voltage level than the voltage level used by the microcontroller, we
decided to use two regulating circuitries. The first one would be responsible to regulate the
voltage from the main source which is 48 Volts to 12 Volts which will be used by the touch
sensing display and one of our sensors. The second regulator is a buck regulator that would be
22
ECE 477 Final Report
Spring 2010
responsible to regulate the voltage from 12 Volts to 5 Volts which is going to be used by the
microcontroller and the Atom board.
To provide a portable storage system, we would like to put an SD card interface to our system. In
achieving this, we planned to use the microcontroller's Serial Communication Interface (SCI) in
communicating to the SD card module. With the help of FAT file-system library that we
matched up with the microcontroller, we were able to write and read from the SD card through
the SD card module. This module was a breakout board that consisted of a SD card port and
header pins that were connected to the SD card port. It is noted that the module will need 3.3
Volts, so we would use an additional buck regulator circuitry that regulated a 5 Volts input to a
3.3 Volts output.
For the communication between the microcontroller and the Atom board, the system will use a
serial communication method. This can be achieved by using the microcontroller's Serial
Communication Interface (SCI) combined with the Atom board's RS-232 interface. To safely do
this, it requires a driver that bridges the SPI and the RS-232 interface. This is where the
MAX3232CD driver will work best. The microcontroller was the heart of the sensing operation
and it would be explained in the next point.
8.3 Hardware Design Narrative
Our microcontroller, the heart of the sensing operation, would be mainly responsible for
organizing the sensor related processes, communicating it to the display system and to manage
the SD card storage system.
In taking the input signals from the sensors, we decided to use the ATD feature of the
microcontroller. The extra components which were needed in interfacing the sensors were Cold
Junction Amplifier for the thermocouples. This amplifier came in a form of a Dual Inline
Package (DIP) so it can be placed to the PCB easily.
To communicate with the Atom board, we wanted to choose the most reliable interface and that
was offered by the SCI of the microcontroller. This interface would give the ease of
communication and the portability that might be needed as the research progress.
23
ECE 477 Final Report
Spring 2010
Alternatives were available for us to interface with the SD card. Among them all, we thought that
SPI would nicely fit our design. Since we also found modules that support the interface between
the SD card and the SPI of the microcontroller, the development process would be accelerated as
well.
Additionally, we also provided Background Debug Mode (BDM) pins that would allow us to
program the microcontroller on the PCB right away. This would help us in debugging the chip if
something went wrong.
To give a complete description of what we are using in terms of microcontroller pins, the pins
usage table is shown below. This table was to be evaluated with the assistance of the 9S12C32
manual for 48 Pin QFP Pinouts.
Pin number
Pin name
Usage
1
PW0/IOC0/PT0
Debug pin
2
PW1/IOC1/PT1
Debug pin
3
PW2/IOC2/PT2
Debug pin
4
PW3/IOC3/PT3
Debug pin
5
VDD1
Power
6
VSS1
Power
7
PW4/IOC4/PT4
Debug pin
8
IOC5/PT5
Debug pin
9
IOC6/PT6
Debug pin
10
IOC7/PT7
Debug pin
11
MODC/BKGD
BDM pin
12
PB4
Not used
13
~XCLKS/PE7
Debug pin
14
ECLK/PE4
Debug pin
15
VSSR
Power
16
VDDR
Power
17
~RESET
BDM pin
24
ECE 477 Final Report
Spring 2010
18
VDDPLL
Not used
19
XFC
Not used
20
VSSPLL
Not used
21
EXTAL
Oscillator
22
XTAL
Oscillator
23
TEST/VPP
Not used
24
~IRQ/PE1
Debug pin
25
~XIRQ/PE0
Not used
26
PA0
Not used
27
PAD00/AN00
ATD pin
28
PAD01/AN01
ATD pin
29
PAD02/AN02
ATD pin
30
PAD03/AN03
ATD pin
31
PAD04/AN04
ATD pin
32
PAD05/AN05
ATD pin
33
PAD06/AN06
ATD pin
34
PAD07/AN07
ATD pin
35
VDDA
Power
36
VRH
Power
37
VSSA
Power
38
PS0/RXD
SCI pin
39
PS1/TXD
SCI pin
40
PM5/SCK
SPI pin
41
PM4/MOSI
SPI pin
42
PM3/~SS
SPI pin
43
PM2/MISO
SPI pin
44
PM1/TXCAN
Debug pin
25
ECE 477 Final Report
Spring 2010
45
PM0/RXCAN
Debug pin
46
VSSX
Power
47
VDDX
Power
48
PP5/KWP5/PW5
Debug pin
8.4 Summary
Our project was a device that monitored the vital information of a research vehicle and shown
the information in a format that it would accelerate the research in developing this particular type
of hydrogen fueled vehicle. It used a touch sensing display that would collaborate with a
microcontroller that takes input from the sensors attached to the vital devices of the vehicle.
The communication between the microcontroller and the Atom board would use a Serial
Communication Interface and an RS-232 interface. In providing the ease of portable storage
system, we used an SD card module interfaced with the Serial Peripheral Interface. The sensors
would be giving the needed information to the microcontroller through an Analog To Digital
interface.
The atom board was responsible for taking user input from the touch sensor and showing the user
the right information about the properties.
When used correctly, we believed that this device would help the research group to focus more
in the development of the vehicle. Hopefully, this device would be more useful than what we
expected.
9.0 PCB Layout Design Considerations
9.1 Introduction
AFCI was an instrumentation device that was designed for a Hydrogen Fuel-Cell electric vehicle.
This product was built with the purpose of a study aid for the research group that develops this
specific vehicle. Hoped that the product would provide the practical advantages to accelerate the
research, we decided to create an instrumentation system that was focused in monitoring the
important physical properties of the vehicle's vital devices as well as giving the ease and the
elegance of using the instrument over a user-friendly interface.
26
ECE 477 Final Report
Spring 2010
In this project, the Printed Circuit Board was the heart where all the vital hardware were laid out.
9.2 PCB Layout Design Considerations - Overall
In order to prevent unnecessary noises we collectively united the power traces and the ground
traces. Both the top layer and the bottom layer of the PCB had the access to these vital
connections. Routing the traces depended to the component placement very closely. It was easier
when we placed the component with the signal routing in mind so that the routing would
naturally adapt to the environment.
The component placement over the PCB was affected by some factors. The first factor was its
dimension. We wanted to have the bigger components which were usually more important to be
away from each other to prevent noises and physical obstruction. The second factor was its
usage. We grouped and placed our components based on their functionality. In this way, the
needed by-pass capacitors' capabilities were extended to their best and it was easier for us to
route the traces as more traces existed for the related components. The third factor was the noise
reduction constraint for the reliability of the product. We wanted to place the noise-sensitive
parts of the PCB away from the noise sources. That would mean we had to place the microcontroller, the sensors and their related component away from the voltage regulators. Lastly, we
wanted to place all of the components so that the ports that were connected were facing each
other to simplify the trace routing process.
Size of the traces followed the minimum width was needed to make sure the signals did not get
weaken in the middle of the system's operation. This varied as the traces had different purposes
to be use. We believed that it was safer to give the priority of a direct tracing route to the signal
traces as they were more vulnerable to all kinds of noises compared to the power traces which
had wider trace size.
In view of the fact that we were using an external connector module for the SD card, we matched
the header pins of our PCB with the sockets available on the SD card module. This SD card
module had to be placed near the edge of the PCB as this module would be in contact to the user
most often. It was also considered to put the module on the same side of the SPI pins of the
micro-controller to make the routing process easier.
27
ECE 477 Final Report
Spring 2010
The position of the serial communication port should be near the edge as well. This would
provide greater ease of connecting the serial cable between the Atom board and the PCB. Also, it
was best to put it on the same side that the corresponding pins exist to avoid detours of traces.
While the position of the debugging pin headers was quite flexible, we wanted to put the pin
headers for the ATD sensors' signals to be on the edge on the board as well. This would give the
flexibility when the sensors need to be changed or unplugged. To avoid additional difficulty in
the trace routing, we also put this on the same side with the ATD pins.
The driver for the RS-232 communication port should bridge the micro-controller's SCI pins and
the communication port. For that goal, it was better to place it on the side of the microcontroller's SCI pins.
9.3 PCB Layout Design Considerations - Microcontroller
Micro-controller was the heart of the sensing operation. In our system we used an external
oscillator. We put the oscillator quite close to the micro-controller.
As the common design practices recommended us, we provided a space that was close enough to
the micro-controller for the bypass capacitors so that they will work on their best to stabilize the
voltage.
Power trace for the micro-controller was bigger than a normal signal trace as it was responsible
for carrying the input voltages. Again, these power connections should come from one single
power point and one single ground point to avoid any unnecessary noises.
To provide the ability to program the micro-controller on the PCB, we put Background Debug
Mode (BDM) pins on the PCB. These pins were quite flexible for placement as they do not serve
any purpose for the real customer of the system. It was acceptable to place it anywhere as long as
the BDM jumper could be plugged onto these pins.
In the view of fact that we would be using the micro-controller's pins from all of the four sides, it
was desirable to put the micro-controller in the center of the PCB. It was wise to give more PCB
space on the side of the micro-controller that has many used pins for routing. Except for power
28
ECE 477 Final Report
Spring 2010
supply circuitry that brought a lot of noise, it was simpler to place the component closer to the
micro-controller's edge when direct tracing route between were possible.
With these considerations in mind, we decided to place the micro-controller so that the lower and
the right side of the micro-controller would be closer to the edge of the PCB compared to the
distance between the upper and the left side to the PCB's edges. We were sure that this would
allow the trace routing enough space for the SPI and the SCI interface which pins share the upper
side of the micro-controller.
9.4 PCB Layout Design Considerations - Power Supply
Power supply related circuitry was a part of the PCB that made huge noise effect to all the other
components. Again, in order to maintain the system reliability during the operation, we placed
the power supply circuitry away from the sensitive component while still keeping the reasonable
size of the PCB.
Just as mentioned on the point before, we needed to have traces as big as sixty mils for the power
supply. These traces should be reliable enough so that we could extend the power traces longer
as it would be connected to various components.
Fortunately, the bypass capacitors needed for this design were not bulky. This reduced the
excessive space necessity of the capacitors. Still, all bypass capacitors should be placed very near
to the related IC to bring its best performance.
The power regulators for this project took a quarter of the PCB’s area. Vertically, it also needed
greater space for the 48 Volts to 12 Volts regulator since this device needed external heat sink to
maintain its temperature.
All of the ICs that used power needed to connect its power related pins to this same power
circuitry output so that they were guaranteed to agree in the voltage references and noises would
be avoided.
29
ECE 477 Final Report
Spring 2010
9.5 Summary
Our PCB layout consisted of a micro-controller in the center, the RS-232 port and the SD card
module on the upper side, the ATD pins header on the right side, the debugging pins header on
the left side and the voltage regulator circuitry on the top left corner of the PCB. The other driver
ICs were placed between the micro-controller and the interfaces they supported. Voltage
regulator circuitry was placed far away from the micro-controller as it could bring undesired
noises. Additional space was provided for the upper side of the micro-controller as the microcontroller needed it for routing the traces since they had more used pins than the other sides. This
PCB design prioritized its usability, robustness and ultimately its functionality to serve the
system's main purpose.
10.0 Software Design Considerations
10.1 Introduction
We are designing an instrumentation and analysis system for a hydrogen-powered golf cart. Its
primary goal is to aid in the research of a very promising hydrogen-fuel technology that Naman
Chopra and Purdue professor Jerry Woodall are developing. The specific values we are
monitoring are the pressure and temperature in the hydrogen reactor and water tank, along with
the hydrogen level just outside the tank, to detect hydrogen leaks. Our project involves an Intel
Atom board which handles the LCD display and the interpretation of touchscreen commands;
and a Freescale 9S12C32 microcontroller which handles SD card interfacing and sampling of
sensor Analog-to-Digital values. Thus, our software requirements are split into two main parts: a
Java application which runs on the Atom board and the CodeWarrior-compiled C code which
runs on our microcontroller.
10.2 Software Design Considerations
We have chosen to use embedded C along with the CodeWarrior IDE and compiler to program
our microcontroller because we have experience with these tools and we can be much more
productive than programming in assembly. We have chosen to use Java and the Swing widget
toolkit to program the Atom board because Java is portable, and easy to use. In addition, Darin
has a lot of experience with these tools. The operating system installed on the Atom board is
Ubuntu 9.10. We have chosen this OS because some of our team members are familiar with it
and because it can be easily booted from a compact flash card.
30
ECE 477 Final Report
Spring 2010
For our project, we have placed a large emphasis on the LCD/touchscreen user interface, as we
want our product to look professional and feel intuitive. It will consist of 5 meters, much like
those seen on a car dashboard, that show the current sensor values. When the user selects one of
those meters, a graph showing the change in that sensor will be displayed. From the main
display, the user can also toggle the logging of each sensor to an SD card, and modify the
logging rate.
Although our project deals with real-time monitoring of a system, we have very loose speed and
performance requirements. This is because the LCD display only updates twice each second and
that is also the fastest possible SD card logging rate for our application. We believe that a ½
second interval between updates is a sensible choice, as it is not so fast that it confounds the user,
but is still fast enough to give a good picture of the current state of the hydrogen fuel system.
Because of our lax speed and performance requirements, we have not included specific
optimizations in those areas. However, given the nature of space constraints on microcontrollers,
we are still careful not to make our code size too large or to utilize unnecessary memory. With
those goals, we have refrained from including any libraries except for a FAT filesystem library
that is very useful for our purposes, and also avoided using dynamic memory allocation.
In order to better illustrate the platform we are writing our software on, this section of the
homework will highlight the important hardware sections of the Freescale 9S12C32
microcontroller. Variables and the stack are placed in SRAM, which is mapped to 0x3800 to
0x3FFF. The stack starts from the “top” of SRAM: 0x3FFF and grows downwards. To minimize
memory usage we are not using the heap in our application. Application code and static data are
placed in Flash, which is mapped from 0x8000 to 0xF7FF. The explicit placing of each variable
within SRAM is determined at compile time by the CodeWarrior compiler and will change as
our application changes.
Region
Mapped Address Space
Register space
0x0000 – 0x03FF
SRAM
0x3800 – 0x3FFF
Flash
0x8000 – 0xF7FF
Resident Debugger
0xF800 – 0xFFFF
Interrupt vectors
0xFF00 – 0xFFFF
Table 10.2-1: Mapped Address Spaces
31
ECE 477 Final Report
Spring 2010
The external interfaces we are using are 5 ATDs, SPI and SCI. Their uses are described in the
table below.
Interface
Usage
ATD5
Sampling Hydrogen Reactor Pressure Transducer readings
ATD4
Sampling Water Tank Pressure Transducer readings
ATD7
Sampling Hydrogen Reactor Temperature Thermocouple readings
ATD6
Sampling Water Tank Temperature Thermocouple readings
ATD3
Sampling Hydrogen Leak Sensor readings
SPI
SD card interfacing
SCI
Communication with Atom board via serial port
Table 10.2-2: Usage of External Interfaces
Register
Flag/bit
Value
Effect
INITRG
(whole)
0x00
Set registers at 0x0000
INITRM
(whole)
0x39
Set RAM to end at 0x3FFF
CLKSEL
PLLSEL
1
Derive system clock from Phased Lock Loop clock
(bus clock = PLLCLK/2 = 12MHz), instead of the
Oscillator clock
SYNR
(whole)
0x02
Sets Phase Locked Loop to 24MHz
COPCTL
RSBCK
1
Stops the watchdog timer and real time interrupts
when the system enters BDM mode
SCIBDL
(whole)
156
Sets SCI baud rate to 9600 baud
SCICR2
(whole)
0x0C
Enable the receiver and transmitter for SCI
DDRB
DDR4
1
Enable port B4 as an output
PORTB
(whole)
0x10
Enable port B4 as an output
RTICTL
(whole)
0x70
Sets the timeout period for the real time interrupt to
216 oscillator clock ticks
CRGINT
RTIE
1
Enable interrupts whenever the real time interrupt
flag is set
ATDDIEN
(whole)
0b11111000 Enable digital input buffers for ATDs 7,6,5,4,3
ATDCTL2
ADPU
1
Enable normal ATD functionality
ATDCTL3
(whole)
0x08
Set ATD to perform 1 conversion per sequence
TSCR2
(whole)
0x0C
Reset timer counter upon a successful compare 7
event. Set timer prescaler clock to bus clock/16
32
ECE 477 Final Report
Spring 2010
TIOS
(whole)
0x80
Set channel 7 as an output compare
SPICR1
(whole)
0b01010000 Enable SPI and make associated port pins dedicated
to SPI functions. Also set SPI as master mode
Set SPI such that the “Slave Select” pin is not used.
SPICR2
(whole)
0x00
SPIBR
(whole)
0b01110111 Set SPI frequency to about 20 kHz
Table 10.2-3: Register Initializations
The above table describes the various register initializations we have used for the 9S12C
microcontroller. The INITRG and INITRM registers are set in accordance with FreeScale’s
recommendations. The clock-related registers are configured to yield a 24MHz system clock,
which is more than adequate for our performance needs. The SCI has been set to 9600 baud
because that is a common baud rate for serial interfaces and is the baud rate set on our Atom
board. Our SCICR2, DDRB and PORTB configurations ensure that the serial TX and RX lines
are enabled, and that the IRQ line is enabled as an output. The ATDDIEN and ATDCTL2
settings are rather self-explanatory as we will be using ATDs 3-7 to sample sensor readings and
for our purposes 1 ATD conversion per sequence is enough. The TSCR2 and TIOS settings
prepare the timer for use but do not actually start it. The microcontroller will wait for a message
from the Atom board which contains the user-configured SD logging interval before it
accordingly sets and starts the timer. Because we only have a single SPI device which is the SD
card reader module and we want the microcontroller to be in control, we set SPI to master mode.
As the core logic of our microcontroller code is relatively simple, we are using an interruptdriven organization. The “main” function will simply perform the required initializations and
wait for interrupts in an infinite for loop. From main, when there is a timer tick interrupt, the
microcontroller updates the wall clock time and logs the desired sensor data onto the SD card. If
there is a message from the Atom board over the serial connection, it will determine the message
content and take an appropriate action. If the message is a sensor data request, the
microcontroller will reply with a message containing the sensor data. If it is a toggle logging
request, the microcontroller will toggle the particular sensor’s logging flag. If it is a wall clock
time message, the microcontroller will set a wall clock time variable and create a file with
filename based on that time. Finally, if it is a logging interval message, the microcontroller will
update the timer tick frequency.
The Atom board code flow is similar - most of the time it will be waiting in an idle state. When
there is a timer event, it will send a sensor data request to the microcontroller. There is a
33
ECE 477 Final Report
Spring 2010
dedicated thread waiting that listens for microcontroller responses. When a sensor data response
is received, the sensor values are checked to see if they are within a safe threshold. If they are
not, a warning is displayed to the user with appropriate safety suggestions. Otherwise, the meter
display or graph is updated with the new sensor values. Apart from that, the Atom board just
needs to respond to user actions such as setting the SD card logging rate, toggling sensor
logging, and displaying different widgets based on the current program status.
10.3 Software Design Narrative
To reduce the complexity of dealing with an SD card FAT filesystem, we are using Roland’s
MMC/SD/SDHC card library which can be found here: http://www.roland-riegel.de/sdreader/index.html Apart from that, we are utilizing the “Java Communications 3.0 API”
(http://java.sun.com/products/javacomm/index.jsp) to perform serial port communications from
within a Java application running on Linux. We are also using JFreeChart
(http://www.jfree.org/jfreechart/), a Java charting library for our graphing needs.
The following module outlines are based on the hierarchy diagrams in Appendix B.
Receive Atom Packet
Description: This is a function that continuously buffers data from the SCI receive register until
it encounters the end of an Atom board message, denoted by a special character. It then casts the
buffered data into an afci_message struct, and based on the message_type field, will
perform the appropriate action.
Progress: This has been written and is working; however, we have yet to standardize our
messages in a way that can be casted into a common struct. This way a received buffer can be
easily transferred to a local struct using memcpy().
Send Packet
Description: Packs current ATD values into an afci_message struct, and sends the struct
over the serial connection.
Progress: This has been written and is working; however, we have yet to standardize our
messages in a way that can be casted into a common struct.
Read ATDs
Description: Simply reads and returns all current sensor ATD values
Progress: This has been written and is working, but for testing purposes we are only using one
ATD.
34
ECE 477 Final Report
Spring 2010
Create File
Description: Performs the necessary steps within the SD card’s filesystem to create a file with
filename equal to the timestamp received from the Atom board at system startup.
Progress: This functionality is provided by the FAT filesystem library we are using, but has not
yet been tested.
SD Command
Description: Sends a command over SPI to the SD card using the correct sequence of
assertions/de-assertions and bytes as defined by the SanDisk SD standard.
Progress: This functionality is provided by the FAT filesystem library we are using, has been
tested and is working correctly.
Timer Interrupt Handler
Description: The interrupt vector the system jumps to upon a timer tick. Will call the “update
wall clock time” and “log sensor value” functions.
Progress: This has yet to be written.
Update wall clock time
Description: Will take in as an argument the duration that has passed between the last time the
internal wall clock time has been updated and the moment the function was called and update the
wall clock time appropriately. The time will be stored in a human understandable
date/hour/minute/second form.
Progress: This has yet to be written.
Log sensor values
Description: For each sensor where its logging flag is set to true, this will open the current SD
file and log an entry in <timestamp><current sensor value> form.
Progress: This has yet to be written.
initialize
Description: Initializes the microcontroller to the appropriate state for the application. Most of
this function’s contents are shown in Table 3.
Progress: This has been written and is working; however, it will evolve when we will require
new/different initializations to test additional parts of our code.
Table 10.3-1: Microcontroller Modules
35
ECE 477 Final Report
Spring 2010
Car Interface
Description: This is a broad module encompassing the entire touchscreen user interface. Swing
widgets are used to display buttons that the user can touch, and a button handler will be called
each time that happens.
Progress: This has been written and is working, but is subject to changes as we have not added
all our final user interface features yet.
Read Serial Port Thread
Description: This is a dedicated thread that listens on the serial port for messages from the
microcontroller. It uses the Java Communications library.
Progress: This has been written and is working.
Data Buffer
Description: Buffers values read on the serial port.
Progress: This has been written and is working.
Check valid string
Description: Checks the buffered serial port data to see if it represents a complete message. If the
message has been mangled, it signals the system to resend the appropriate message.
Progress: This has been written and is working, but we have not yet included the “resend”
feature.
Update chart (if needed)
Description: If the LCD is in graph display mode, updates the graph based on the new sensor
data.
Progress: This has been written and is working, but we are currently using a scatter plot and
have yet to successfully draw a correct line graph.
Update Panels (if needed)
Description: If the LCD is in meter display mode, updates the meters based on the new sensor
data.
Progress: This has been written and is working.
Timer interrupt
Description: The interrupt handler for a Java timer tick. Invokes the “send serial port” module to
send a sensor data request.
Progress: This has been written and is working.
Send serial port
Description: Creates and sends a message over the serial port. The type of message to be sent is
taken in as a function argument
36
ECE 477 Final Report
Spring 2010
Progress: This has been written and is working. However, we plan to standardize our message
contents and lengths.
Meter panels
Description: This represents the meter panels that display the current corresponding sensor
value. These can touched to show a graph for that sensor’s values.
Progress: This has been written and is working. We do plan on greatly improving the aesthetics
of these meters by using custom sprites.
JFreeChart
Description: This is the Java library we are using to draw a graph for a given sensor’s values.
Progress: This has been tested and is working, however we are currently only able to draw a
scatter plot, whereas what we want to use is a line graph.
Table 10.3-2: Atom Board Modules
10.4 Summary
This report provides relevant software and hardware details for our microcontroller, explanations
for design choices we have made in light of our software design considerations, and details
regarding the mechanics and organization of our software design, which at this point may still be
subject to change.
11.0 Version 2 Changes
There are many new features that we can add if there were a version 2 for the AFCI system.
Many of the changes have to deal with the microcontroller functionality along with the overall
user interface.
One change we can make to our system is to allow the user to change the log rates of
multiple sensors. As of now AFCI only allows one logging rate for the SD card for every sensor.
In order to change this instead of there being only one log rate change panel at the top, there will
be a log rate change panel for each meter panel also the one meter mode panels and two meter
mode panels.
Another feature we can implement is to allow the user to be able to change the
threshold warnings using the interface or the computer. Right now the threshold values are hard
37
ECE 477 Final Report
Spring 2010
coded into Java application and will require a re-compile if the user wants to change them. One
way to change them would be to have a pop up window that will allow the user to change each
threshold value. Also another way would be to have an XML configuration file where the user
can easily edit the file and change the threshold values.
Lastly, since the Java application will be running a computer, an option could be
added to allow the user to store the log onto a file on the computer rather than the SD card. This
way just in case the user doesn’t have an SD card they can still log the data values if they want
to.
12.0 Summary and Conclusions
The AFCI system was able to successfully fulfill all 5 Project-Specific success criteria. However
there are still some improvements that need to be made. The biggest one is the replacement of
the atom board. Since our atom board died we needed to use our laptop in order to demonstrate
our product. However for research purposes this would not be very convenient for the research
team. We are going to attempt to send the atom board back to Advantech to see if they can repair
it. After it comes back a member on the research can attempt to install the atom board to work
with our system.
Doing this project has taught us a lot of things regarding actually creating a usable product.
Packaging, although it seems trivial, can be very difficult to do successfully. Also PCB design
was a good experience for us as none of us has had any prior experience. Looking at datasheets
and trying to design the right circuit also takes a bit of practice and understanding. Our previous
courses taken has helped us in this aspect.
Although the AFCI system is not perfect we believe the idea of providing a nice user interface,
even for research purposes, to monitor data is a good one. We hope that our project will aid the
research of Professor Woodall.
13.0 References
[1] Walter R. Boyd, “Methods for Monitoring Hydrogen Fueling Systems”, U.S Patent
20090297897, December 5, 2008
38
ECE 477 Final Report
Spring 2010
[2] Peter V. Zanardelli, “Computer System and Method for Monitoring Hydrogen Vehicles”,
U.S. Patent 20080234888, December 1, 2005
[3] Herbert J. Hofmann, “Golf course management system for golf carts”, U.S. Patent
20090201263, February 9, 2009
[4] D. G. Meyer, “Module 1 Microcontroller Assembly Language Programming Techniques”
ECE 362 – Microprocessor Systems & Interfacing, 2009. [Online]. Available:
https://engineering.purdue.edu/ece362/Notes/2010_spring/Mod1.pdf [Accessed: March 25,
2010].
[5] “The Stack”, publication date unknown. [Online]. Available:
http://www.ece.utep.edu/courses/web3376/Stack.html [Accessed: March 25, 2010]
[6] Freescale Semiconducters, “MCS9S12C Family Device User Guide”, January 25, 2003.
[Online]. Available:
https://engineering.purdue.edu/ece362/Refs/9S12C_Refs/9S12C128DGV1.pdf [Accessed:
March 25, 2010]
[7] Connecticut Department of Environmental Protection, “Batteries (Lead Acid)” Pit Stops
Fact Sheet, 2004. [Online]. Available:
http://www.ct.gov/dep/lib/dep/p2/vehicle/batteriesleadccid.pdf [Accessed: April 21, 2010].
[8] Call2recycle, “Recycling Laws & Regulations”, publication date unknown. [Online].
Available: http://www.call2recycle.org/laws.php?c=1&d=79&e=104&w=2&r=Y
[Accessed: April 21, 2010]
[9] U.S. Environmental Protection Agency, “Batteries” Wastes – Resource Conservation –
Common Wastes & Materials, August 28, 2008. [Online]. Available:
http://www.epa.gov/waste/conserve/materials/battery.htm#batteryrecycle [Accessed: April
21, 2010]
[10] Department of Defense, “Military Handbook – Reliability Prediction of Electronic
Equipment,” MIL-HDBK-217F, Feb. 1990. [Online].
39
ECE 477 Final Report
Available:
Spring 2010
https://engineering.purdue.edu/ece477/Homework/CommonRefs/Mil-Hdbk-
217F.pdf
[11] Walter R. Boyd, “Methods for Monitoring Hydrogen Fueling Systems”, U.S Patent
20090297897, December 5, 2008
[12] Peter V. Zanardelli, “Computer System and Method for Monitoring Hydrogen Vehicles”,
U.S. Patent 20080234888, December 1, 2005
[13] Herbert J. Hofmann, “Golf course management system for golf carts”, U.S. Patent
20090201263, February 9, 2009
[14] “Nissan USA website” [Online],
Available: http://www.nissanusa.com/gt-r/. [Accessed Feb. 11, 2010]
[15] “Toyota website” [Online],
Available: http://www.toyota.com/prius-hybrid/. [Accessed Feb. 11, 2010]
[16] Freescale Technical Staff, MC9S12C Family Reference Manual, Freescale Semiconductor,
Inc., 2006 Available: http://www.freescale.com [Accessed February 4, 2010]
[17] Atmel Technical Staff, ATmega16 Datasheet, Atmel Corporation, 2009 Available:
http://www.atmelcom [Accessed February 4, 2010]
40
ECE 477 Final Report
Spring 2010
Appendix A: Individual Contributions
A.1 Contributions of Suan-Aik Yeo:
Over the course of the semester I tried to help out as much as I could, especially in areas where I
am skilled in relative to the rest of the team. Although I was not the team leader, I still took it
upon myself to do a lot of organization, such as organizing team meetings and making sure
everybody’s progress was on track with our plans.
I also took it upon myself to be the team webmaster, since I had the most experience with web
design and programming. I created our team website early in the semester using the same
template I use for my homepage because I felt that the website would be essential to keeping the
team organized. I tried to make the website as useful as possible to the team, providing links to
our graded and ungraded homework, to our Google Docs shared folder, to the ECE 477 home
page and so on. I also installed Cygwin and SSH on the team desktop so that we would be able to
access it remotely as long as it was powered on. I created directories within our website such as
“ungraded homework” and “datasheets” and encouraged team members to place their work
there. Furthermore, I set up a Google Docs folder where we could share collaborative
documents. It has been proven to be a tremendous help.
Next I moved on to designing our power supply. Powering our system directly through the golf
cart’s 48V battery seemed to be the most logical and convenient method. However, all the 48V
to 12V regulators that we were able to find that had enough output power for all our components
were about as large as a brick and cost over a hundred dollars. After discussions with the course
staff we decided to get a dedicated 12V battery to power our system. By sheer luck, around this
time I stumbled upon a used 33-75V to 12V regulator on EBay which had 4.2A output and was
selling for under $40. I immediately ordered the part and based our power supply off of it. With
our entry point regulator decided upon, with Ronny’s help I outlined and acquired the parts for
the rest of our power needs: an LM22677 12V-5V switching regulator and a TPS7233QP 5V3.3V linear regulator. Eventually we were also going to need an LM7805 12V-5V linear
regulator to eliminate noise on the power line created by the Atom board. When we found out
that a golf cart with a 48V battery would no longer be available, I also found and ordered a 36V
lead acid battery to use with our design for demonstration purposes.
A-1
ECE 477 Final Report
Spring 2010
Another important contribution I made was to do much of the programming for the Freescale
9S12C32 microcontroller we are using and to implement SD card interfacing. I was responsible
for this because I used CodeWarrior with the same microcontroller and also worked with SD
cards when I took ECE 362. I spent around a week trying to get Roland Riegel’s SD FAT library
to work with CodeWarrior and our microcontroller, but it seemed to use too much SRAM and
was incompatible with the CodeWarrior compiler. As a result I had to code FAT16 file write
functionality from scratch. It helped that I could reuse some initialization code that I wrote
during ECE 362.
I was also solely responsible for all aspects of the Atom board with the exception of the Java
application. I chose and ordered the board itself and made sure its ATX power line was fine and
that the board was working properly. I also configured it to boot from a Compact Flash card
installed with Ubuntu 9.10. Furthermore, I performed many tweaks on the Ubuntu installation
such as removing the launching the Java application on startup, removing all panels to ensure a
true fullscreen experience, and removing the GRUB menu during boot. I also installed the
touchscreen drivers and ensured the touchscreen was operational.
Finally, I created the graphics for our user interface, taking heavy inspiration from the display of
the Nissan GT-R. I know that user interfaces have a heavy impact on the impression any project
makes, and as such I made sure my Photoshop skills were put to good use to create some
impressive graphics.
I was responsible for the Software Design Narrative and Social/Political/Environmental Analysis
homeworks and TPSCs.
A.2 Contributions of Darin Tanaka:
The main responsibility I had on my team was the software for both the Atom Board and the
micro controller. For the Atom Board we were running Ubuntu Linux version 9.10. Since our
system would rely on UART for communication between the Atom board and the micro
controller I needed to setup the environment on the Ubuntu platform to support this protocol.
First I needed to decide which framework would be used for the user interface. I decided I would
go with Java since I have the most experience with it and also because there is already an
A-2
ECE 477 Final Report
Spring 2010
existing API for serial communication. Ubuntu needs a couple of libraries in order to use this
API, so I was able to find them and install it. However I also researched on how to port the Java
interface to a Windows platform just in case a future Windows user wanted to use it.
Also I helped setup the high level communication protocol that would be used between the
microcontroller and Atom board. This involved deciding on the struct definition that would be
used for our protocol. At first we went with a string approach however since strings can have
varied lengths based on current values we decided to go with a struct instead. By designing this
high level protocol I also in turn help setup the micro controller and atom board features that
would be available to the user.
The biggest part I had in this project was the Java GUI. I wrote all the code for Java application
along with the serial communication on the Atom board. Even though I wrote the Java
application we designed the GUI as a team. I setup meter displays along with the log changing
rate communication. Also in the GUI I implemented a user configurable display. There are three
display modes: 5 meter, 2 meter, and 1 meter mode. In order to model the Nissan GT-R, which
was our original intention, I incorporated a graphing feature where the user can see a graph
display of any of the sensor data. However the sprites for the GUI were not made by me.
Since I helped with the communication protocol design I also wrote code for the micro controller
as well. Mainly I wrote code to support the communication protocol. At first we were using
polling-driven SCI with SD writes in a timer interrupt. However our communication was very
unstable as we were losing data every once in a while. This motivated the change to an interrupt
driven SCI which I setup on the micro controller. I also helped with the ATD 8-bit conversions
to actual sensor values (Celsius, PPM, PSI).
Not all of my contributions were just about the software. Before the final PCB schematic
submission I went over the PCB with Ronny to make sure everything was in check. Also I
bought the thermocouple amplifiers along with a LCD touch screen (which didn’t work twice).
Going over GUI designs and system designs was something I also did regularly
A.3 Contributions of Ronny Wijaya:
Ronny Wijaya was responsible mainly in the PCB development process of AFCI project. This
includes learning the tutorials for all the PADS software, designing and creating the schematic
on the PADS Logic software, designing and creating the PCB layout on the PADS Layout
A-3
ECE 477 Final Report
Spring 2010
software, routing the PCB connection on the PADS Router software, putting all the PADS
related files together for Chuck to submit.
During the earlier part of the semester, Ronny spent his time mainly on getting familiar with the
PADS software through the tutorials available from the staffs. Along with the PADS software,
Ronny also tried to work with the preparation for programming the ATMEL micro-controller.
Initially, the team decided on using an ATMEL micro-controller. After some discussion with the
team and the staffs, we changed our choice into a Freescale micro-controller to save some
development time since the other team members know how to integrate the Freescale microcontrollers with an SD card.
On the schematic development process, Ronny assisted the team in researching on the needed
components for the PCB. This includes analyzing the requirements, looking on many
specifications, matching up the sizes and the purchasability, and purchasing the components.
Ronny also created the schematic design on the PADS Logic software for the PCB design. This
involved creating or taking the component decals on the libraries, matching up all the
connections and figuring the needed interfacing media between the PCB and the external
components.
Subsequent to the schematic design, Ronny worked on the PCB layout design on the PADS
Layout software. In this design, Ronny evaluated the physical sizes of the components and what
connections they have to figure the best way to place and orient all the components. During this
process, Ronny made sure that the components have extra length of solder pads so that the
soldering process would be accelerated.
After the PCB layout design was ready, Ronny continued on routing the connections of the PCB
on the PADS router software. In this process, Ronny verified that every traces had sufficient
width as it was needed. To decrease the number of vias and the length of the traces on the PCB,
Ronny manually routed most of all the traces.
On the final submission, Ronny confirmed the design with the team and the staffs. He then
submitted the design for manufacturing through the staff.
Once the manufactured PCB has arrived, Ronny ensured that the PCB was as designed. Together
with Naman Chopra, he soldered and installed all the components on the PCB while constantly
made certain that no wrong connections were made. Unfortunately, Ronny found some mistakes
A-4
ECE 477 Final Report
Spring 2010
that he made on the PCB and so many problems on the solder joint connections. He spent a large
amount of time debugging and ensuring the correctness of the PCB connections.
Finally, Ronny helped Naman in packaging the PCB and the Atom board once the software and
the soldering were finished. This also includes constant testing of the system during the
packaging process.
Ronny also contributed administratively on a couple of homeworks and a couple of presentations
about the team progress on design components.
A.4 Contributions of Naman Chopra:
My role greatly varied over the course of semester. I was heavily involved with most design and
development of the project throughout the semester. It was all my idea in the first place to go
ahead with this project. Even before the course started, in December 2009, I suggested the team
that there is a need for an on-board driver’s instrumentation for the research project which I was
working on. I motivated the team to make a senior design project which will accelerate the
research progress of professor Woodall. So, naturally, it was my responsibility to decide what all
parameters we are going to monitor, how we are going to go around doing it, how the final
product should look like, and by when we need the product to be done. It was my responsibility
to assign tasks over the course of the semester to team members on the basis of their prior
experience with that particular task. I tried my best to keep the team on track and follow a strict
guideline.
There was one time during the semester when I was off limits to the golf cart and the reactor
vessel situated at Herrick laboratories. I was the only one from the team who has permission to
work in Herrick laboratories. Prof. Fritz had to deal with bad health and death in family so he
was on indefinite leave and I was only allowed to work on the cart under his supervision, so that
slowed the progress of the project drastically. So it was my responsibility to find alternative
environments to thoroughly test our system by creating artificial temperature, hydrogen leak
testing and pressure changes in and around the senior design lab.
It was my responsibility to intervene when necessary to aid the group in resolving issues. There
were times when the team had to make decisions regarding change of PSSC’s and then there
A-5
ECE 477 Final Report
Spring 2010
were safety issues relating to water level sensors in high pressure, volatile tanks which I
successfully addressed. Being the team leader, if the team could not reach consensus then my
decision was final.
I did the majority of PCB soldering. I burnt my hand once while using the hot glue gun. I
attended soldering tutorial by course staff and did all surface mount and made/soldered ATX
header. I crimped battery connectors and drilled holes in the thick aluminum box. I suggested the
use of ventilating grill in front of the enclosure for air flow. Chuck helped us a lot in giving
suggestions for packaging and doing some metal work for us.
A-6
ECE 477 Final Report
Spring 2010
Appendix B: Packaging
Figure B-1 Top View of Product Packaging (open box)
B-1
ECE 477 Final Report
Spring 2010
Appendix C: Schematic
Figure C-1: Power management block
C-1
ECE 477 Final Report
Spring 2010
Figure C-2: The micro-controller block
C-2
ECE 477 Final Report
Spring 2010
Figure C-3: The sensors block
C-3
ECE 477 Final Report
Spring 2010
Figure C-4: The SD Card block
C-4
ECE 477 Final Report
Spring 2010
Figure C-5: The RS-232 block
C-5
ECE 477 Final Report
Spring 2010
Appendix D: PCB Layout Top and Bottom Copper
Figure D-1: PCB (Overall)
D-1
ECE 477 Final Report
Spring 2010
Figure D-2: PCB (Top)
Figure D-3: PCB (Bottom)
D-2
ECE 477 Final Report
Spring 2010
Appendix E: Parts List Spreadsheet
Component
Model
Details
Price
Microcontroller
MC9S12
16-bit, 48 pins
$11.88
PCM-9361_DS
2.38 A max, ATX
$300.00
JQIN-116G-12
K-type, cold junction
$23.00 x 2
PMP1260
Up to 100 psi
Not paying
800TSV
8”,1024 x 768
$100.00
AD595-AQ
K-type, cold junction
$17.95 x 2
(Freescale)
Atom Board
(Advantech)
Thermocouple
(Omega)
Pressure transducer
(GE)
LCD touch screen
(Xenarc)
Thermocouple
amplifiers
support, 0 to 480
(Analog Devices)
Celsius
48-12V Regulator
VKP100MT312
2 channel 12
(CD Technologies)
$33.00
vdc/4.2A
1 channel
3.3vdc/30A
5-3.3 V Regulator
TPS7233QP
0 to 250 mA
$2.02
LM22677
4.5 to 42V input
Free Samples
(Texas Instruments)
12-5V Regulator
(National SemiCond)
range
Up to 5A
4 channel
MAX3378E
Up to 16Mbps data
bidirectional logic
Free Samples
rate
level converter
(Maxim)
SD Card Reader
BOB-00204
SD socket
$17.95
(4UCON)
Resisters
Free
Capacitors
Free
E-1
ECE 477 Final Report
12-5 V Linear
Spring 2010
LM7805
Free
Regulator
36 V Lead Acid
B02-137
12 Ah
Battery
TOTAL
$653.74
E-2
$106.99
ECE 477 Final Report
Spring 2010
Appendix F: FMECA Worksheet
Failure
Method of
Failure Mode
Possible Cause
Failure effects
A1
Output = 0 V
Battery or regulator connection
Power lost
Observation
Medium
A2
Output > 5 V
Battery or regulator connection
Might damage parts
Observation
Medium
A3
Untolerated output
Battery, bypass capacitors, or
Might damage parts,
regulator connection
unpredictable
Observation
Medium
Loss of information
Observation
Medium
Loss of information
Observation
Medium
Loss of information
Observation
Medium
no.
B1
B2
B3
C
D
Output 0
Micro-controller, connections,
continuously
or oscillator
Output 1
Micro-controller, connections,
continuously
or oscillator
Unsynchronized
Micro-controller, software, or
oscillator
Sensors are no
Sensors, amplifier IC, or
accurate
physical connection
SD Card is not
Micro-controller, software,
written
regulator, bit translator IC, or
Loss of information
Cannot log information
F-1
detection
Input signals
observation
SD card module
signals
Criticality Remarks
Medium
Low
Proper
connection
Proper
connection
Heat sink
Proper
soldering
Proper
soldering
Solid
software
ECE 477 Final Report
Spring 2010
SD card physical connection
E
RS-232 does not
communicate
observation
Micro-controller, software,
Cannot display
driver IC, or physical
information and disable
connection
user's touch input
F-2
Observation
Medium
Solid
software