ECE 477 Final ReportSpring 2013
Team #3
Team Members:
#1:
Josh Hunsberger
Signature:
JAH
Date: 4-29
#2:
Spencer Julian
Signature:
SMJ
Date: 4-29
#3:
Robert Harris
Signature:
RGH
Date: 4-29
#4:
Ryan Pawling
Signature:
RGP
Date: 4-29
CRITERION
Technical content
Design documentation
Technical writing style
Contributions
Editing
Comments:
0
0
0
0
0
1
1
1
1
1
2
2
2
2
2
3
3
3
3
3
SCORE
4 5 6 7
4 5 6 7
4 5 6 7
4 5 6 7
4 5 6 7
8
8
8
8
8
9
9
9
9
9
10
10
10
10
10
MPY
3
3
2
1
1
TOTAL
PTS
ECE 477 Final Report
Spring 2013
1.0 Table of Contents
Abstract ........................................................................................................................................... 1
3.0 Project Overview and Block Diagram ................................................................................. 1
4.0 Team Success Criteria and Fulfillment ................................................................................ 3
5.0 Constraint Analysis and Component Selection.................................................................... 5
6.0 Patent Liability Analysis .................................................................................................. 100
7.0 Reliability and Safety Analysis ........................................................................................ 104
8.0 Ethical and Environmental Impact Analysis...................................................................... 20
9.0 Packaging Design Considerations...................................................................................... 24
10.0 Schematic Design Considerations...................................................................................... 28
11.0 PCB Layout Design Considerations .................................................................................. 32
12.0 Software Design Considerations ........................................................................................ 34
13.0 Version 2 Changes ............................................................................................................. 39
14.0 Summary and Conclusions ................................................................................................ 40
15.0 References .......................................................................................................................... 41
Appendix A: Individual Contributions ......................................................................................... 1
A.1 Contributions of Josh Hunsberger: ................................................................................... 1
A.2 Contributions of Spencer Julian: ...................................................................................... 3
A.3 Contributions of Robert Harris: ....................................................................................... 5
A.4 Contributions of Ryan Pawling: ......................................Error! Bookmark not defined.
Appendix B: Packaging ................................................................................................................ 1
Appendix C: Schematic ................................................................................................................ 1
Appendix D: PCB Layout Top and Bottom Copper .................................................................... 1
Appendix E: Parts List Spreadsheet ............................................................................................. 1
Appendix F: FMECA Worksheet ................................................................................................. 1
-ii-
ECE 477 Final Report
Spring 2013
2.0 Abstract
The contents of this report describe the design process of our project. This takes into
account our design constraints,packaging, schematic, PCB, and software considerations. Patent
liability and reliability issues are examined in detail. The ethical and environmental impact of the
design is evaluated. The appendices include individual contributions of each team member,
packaging diagrams, schematics, PCB layout, the parts list, and the FMECA worksheet.
3.0 Project Overview and Block Diagram
The Hackers of Catron is an electronic board game based around the incredibly popular
game The Settlers of Catan. The object of the game is to create the largest settlement on the
island of Catron, by obtaining and trading various resources. The board automates game setup,
tracks placement of physical pieces, and provides feedback to players. Resource trading is
managed through handheld devices. These enhancements to the game make it easier to set up
and play, resulting in a much improved game play experience.
Figure 1-1 Block Diagram
-1-
ECE 477 Final Report
Spring 2013
Figure 1-2 Finished Design
-2-
ECE 477 Final Report
Spring 2013
4.0 Team Success Criteria and Fulfillment
4.1 PSSC 1
An ability to generate a random Catan board and represent the resources and their
relative scarcity visually
At the start of a new game, a new random board is generated. This is done by
randomly selecting the 6 resource types and 10 rarities from a pool and assigning them to
each hexagon on the board. Each hexagon displays its resource type and rarity using RGB
LEDs and a seven segment LED display. We fulfilled all the needs of this PSSC.
4.2 PSSC 2
An ability to detect the placement of pieces on the board and update the game status
accordingly
The board maintains a game state of all the pieces placed on the board and continually
checks for new pieces and provides feedback to the user whether they are legally or
illegally placed as per the game rules. By means of Hall Effect sensors, the board is able
to accurately sense the placement of pieces. The requirements of this PSSC were met.
4.3 PSSC 3
An ability to display game status (current scores, resources, etc.) via a web interface
The board notifies the pi of how many points and resources are acquired depending on
the game state so that they can be displayed on the web interface for players to view. The
players are clearly able to view how many points they have and what their resources are,
as well as any development cards they own and what the dice roll is. This PSSC was fully
realized.
4.4 PSSC 4
An ability to enforce correct turn based gameplay via the board lighting and web interface
The majority of the turn structure is handled using the web interface. Players must
first roll before trading or purchasing, and development cards can be played at any time.
-3-
ECE 477 Final Report
Spring 2013
The board and web interface work together to maintain turn order and player order. A
game of Catan can be played start to finish using The Hackers of Catron, meaning this
PSCC is met.
4.5 PSSC 5
An ability to handle resource trading between players via the web interface
The web interface handles trading resources between players. Players are able to
specify which resources they would like to give up in exchange for what they receive.
Other players are able to accept or deny the deal. This PSSC was accomplished.
-4-
ECE 477 Final Report
Spring 2013
5.0 Constraint Analysis and Component Selection
The game board is approximately 15” x 16”, is composed of 19 hexagons, and has 145
possible piece placement positions. Each of the 19 hexagons must be able to be randomly
denoted as a resource of brick, lumber, wool, grain, or ore at the time of the game setup. Also at
startup, each hexagon should be associated with a number between 2 and 12 to create a mapping
between a roll of two die and the hexagons. Both the resource and number value of a hexagon
must be displayed throughout the game on the physical board. This display method, the piece
sensing, and the link to handheld devices present the most important design constraint issues of
the project.
5.1 Design Constraint Analysis
The design constraint analysis portion of this report is divided into 7 subsections. First, the
computation requirements of the microcontrollers will be discussed. Second, the interface
requirements section will explain how all of the devices will be interconnected and the resulting
I/O functions, number of I/O pins, etc. that are need for the devices. Next, on-chip and off-chip
peripheral requirements will be discussed. Then, power and packaging constraints will be laid
out. Finally, cost constraints of the project will be given.
5.1.1 Computation Requirements
In order to support the handheld devices a motherboard device capable of running an apache
server, an access point, and python code will be needed. Handheld Wi-Fi enabled devices will be
able to connect to a specified access point that will give access through a browser to the
handheld portion of the game. A very flexible and powerful device running Linux will be needed
for this because running an access point and apache server requires a lot of driver and hardware
support.
A microcontroller will be needed for the piece detection and game display. The display will
consist of RGB LED’s and 7-segment displays to identify the resource type and number value of
each hexagon. There aren’t any special computational requirements needed for the display
because, as will be discussed later in the report, drivers will be used for all of the LEDs.
However, piece detection will require some careful planning in terms of computation
requirements. There are 145 positions that must be sensed, so sensing will be time consuming for
the micro controller.
Also, the longest path algorithm (used to determine the longest road on the board) will
become complex as there are more roads added to the board, because it is an NP-hard problem
(although it will be somewhat simplified in our case due to not all nodes being possible
waypoints). Given the combination of piece sensing and longest path processing our
microcontroller would benefit from a relatively high clock speed. The piece sensing and longest
-5-
ECE 477 Final Report
Spring 2013
path processing should be fast enough that (to the user) the feedback appears to occur
instantaneously. Also, no floating point support is needed.
5.1.2 Interface Requirements
First, devices that expand the capability of the microcontroller will be discussed and will
lead into the interface requirements of the micro controller. The 145 sensors will interface with
the microcontroller by way of 18 8:1 multiplexers. Each multiplexer output will feed directly
into a GPIO pin on the microcontroller. However, 18 8:1 multiplexers only take care of 144
sensors, so 1 sensor will be fed directly into a GPIO pin. A total of three GPIO pins will be
needed for selecting the multiplexer output (all multiplexers will receive the same select value
and the microcontroller will choose the appropriate input signal to read).
There will be 2 RGB LEDs per hexagon to display what resource is located there (each
resource corresponds to a specific color). A two wire interface will be used to connect 7
addressable RGB LED drivers (with gradation control) that each drive RGB LEDs for three
hexagons [1]. An I2C interface will be needed on the microcontroller for the TWI.
There will be 2 7-segment LED displays per hexagon to show the numeric value of the
resource at that location. LED drivers capable of driving 8 7-segments at a time will be used.
Five drivers will be used, and they are addressable using SPI [2].
Finally, the motherboard device must be able to communicate with the micro controller
using either I2C or UART (after further research is done about Python support for the two, one
will be picked). The motherboard must have a USB interface to communicate with a wireless
adapter that has access point support.
Due to the fact that drivers are being used, there are no stringent current constraints for the
microcontroller I/O pins because they are all connected to other CMOS I/O pins. The drivers
can both operate at 3.3V so VOH should be 3.3 for the I/O pins on the microcontroller [1] [2].
The on-chip peripheral requirements will be discussed in the next section (On-Chip
Peripheral Requirements) and a chart with a summary of the on-chip peripherals can be seen
below in Table 3-1 - Interface/On-Chip Peripheral Requirements Summary. The off-chip
peripheral requirements will be discussed in Off-Chip Peripheral Requirements and a chart with
a summary of the off-chip peripherals can be seen in Table 3-2 - Off-Chip Peripheral Summary.
5.1.3 On-Chip Peripheral Requirements
The microcontroller will need 1 SPI and 2 I2C/UART on-chip peripherals in order to
communicate with the 7-segment display drivers, RGB LED drivers, and the motherboard. No
ATD or DTA channels are needed. The motherboard will need 1 I2C/UART channel and a USB
port. See Section 3.1.2andAppendix E for more details on how the components are all
interconnected.
-6-
ECE 477 Final Report
Spring 2013
Table 3-1 - Interface/On-Chip Peripheral Requirements Summary
Microcontroller
Motherboard
Quantity Description
Quantity Description
22
General Purpose I/O
1
UART/I2C
2
UART/I2C
1
USB
1
SPI
5.1.4 Off-Chip Peripheral Requirements
Several off-chip peripherals are needed for the project to interface with the many sensors
and LEDs on the board. LED drivers, 7-segment drivers, and 8 to 1 multiplexers will interface
with the microcontroller. The motherboard will need an external wireless adapter with software
access point capability. See Section 3.1.2 and Appendix E for more details on how the
components are all interconnected.
Table 3-2 - Off-Chip Peripheral Summary
Quantity Description
Interface Interfaced With
5
7-Segment Driver
SPI
Microcontroller
7
LED Driver
TWI
Microcontroller
18
8:1 Multiplexer
GPIO
Microcontroller
1
Wireless Access Point Adapter USB
Motherboard
5.1.5 Power Constraints
The device will not be battery powered, it will be A.C. powered only. The majority of the
power consumption of the project will be due to the LEDs on the board (38 RGB LEDs and 40
7-segment displays). The PCB will be very large (approximately 15” x 16”) so heat dissipation
should not be a significant issue.
The max power consumption for the project will be 16.4 Watts. Of that total, the RGB LEDs
and 7-Segment LEDs will consume 9.5 Watts and 2.8 Watts, respectively, at peak draw [1] [2].
5.1.6 Packaging Constraints
The packaging needs to be the size of the original Settlers of Catan game (approximately
15” x 16”), so there should be no issue with fitting all of our pieces in the package. However, the
board should be “light enough” that it is movable. The resource colors need to be visible.The
opacity of the frosted acrylic that forms the top layer of the board game should be such that the
light from the RGB LEDs is scattered somewhat, yet the 7 segment displays are easily visible.
The space between the top of the board and the PCB should be close enough for the Hall Effect
sensors to detect piece placement (the exact distance will vary based on the strength of the
magnets used).
-7-
ECE 477 Final Report
Spring 2013
5.1.7 Cost Constraints
The cost constraints of the project will be very difficult to meet with the initial prototype
that is being designed. The cost of the project will be around $500-$600 including the large PCB
and packaging. This price would be cut drastically if the product were produced on a mass scale.
Prices for a few devices similar to the project are shown below. All of the alternatives are much
cheaper than the cost of the Hackers of Catron prototype will be [3] [4] [5] [6]. However, this
project definitely fits into a niche market. We have not been able to find any board games that
have a physical board and pieces, yet fully integrated electronic scoring and board setup. Having
the physical pieces along with the electronic trading and economy will be a very unique and fun
experience that other games cannot provide.
Table 3-3 - Cost Comparison
Cost (USD) Description
42.00 Catan board game (no electronics) [3]
4.99 iPadCatan Game [4]
2.22 Online Catan game, monthly subscription [5]
24.99 Monopoly board game with electronic banking system [6]
5.2 Component Selection Rationale
See Table3-4 - Microcontroller Comparison for a comparison of the two microcontrollers
considered for the project. Both microcontrollers meet all of the basic needs of the project. The
Atmel microcontroller was chosen for several reasons. First, the higher clock rate and 32-bit
CPU are a big plus, because as pointed out in Section 3.1 the microcontroller does need to have a
decent amount of computation power. Also, our team has more experience using Atmel devices.
Cost is not a major factor because free samples are available. We are already in the process of
testing a sample of the Atmel microcontroller selected.
Table 3-4 - Microcontroller Comparison
Atmel AT32UC3B064
Microchip PIC24FJ64GB004
32-bit
16-bit
Architecture
2-3.6 V
Operating Voltage 3-3.6 V
44 I/O Pins
35 I/O Pins
I/O Pins
 3 USART (also SPI)
 2 UART
2
 1IC
 2 I2C
 1 SPI
 2 SPI
60 MHz
32 MHz
Clock Speed
64 KB
64 KB
Flash Memory
16 KB
16 KB
SRAM
$7.48, Free Sample Available $3.74, Free Sample Available
Pricing
-8-
ECE 477 Final Report
Spring 2013
See Table 3-5 - Motherboard Comparison for a comparison of the two motherboard devices
considered for the project. The Raspberry Pi was an easy choice for several reasons. First, the Pi
is very affordable; however, the Beagle board is out of our price range because of other
expensive components (145 sensors, large PCB, etc.). The Pi has great hardware specs and best
of all has a very good user base online and thus lots of documentation/blog posts. There is even
some documentation on setting up an access point with the Raspberry Pi.
Table 3-5 - Motherboard Comparison
Raspberry Pi Model B
Beagle Board
Broadcom BCM2835
OMAP3530
SOC
ARM1176JZFS
ARM Cortex-A8
CPU
2
UART/I C
UART/I2C
I/O
SPI
SPI
USB 2.0
USB 2.0
700 MHz
600 MHz
Clock Speed
SD Card
256 MB + SD Card
Flash Memory
512 MB
128 MB
SRAM
$35.00
$149.00
Pricing
5.3 Design Constraints Summary
Many different design constraints and component choices have been detailed to this point.
The major design constraints are related to piece sensing, displaying the game status, and
connecting to handheld devices. Sensing piece locations and displaying the game status require
driving and reading over 200 components on the game board. To greatly simplify the I/O needs
of the microcontroller, LED drivers and multiplexers were chosen to interface between the
microcontroller and the board components. A Raspberry Pi was selected for the motherboard
device because it is the cheapest, easiest way to get a software access point and web server
running.
In the end, the goal of this project is to enhance certain portions of the game while keeping
the traditional feel of a board game. The design constraints and component selections were made
with this goal and all 5 of the Project Specific Success Criteria as our top priorities.
-9-
ECE 477 Final Report
Spring 2013
6.0 Patent Liability Analysis
The patent liability for Hackers of Catron stems primarily from two main functions. First
it recognizes the position and types of pieces placed on its physical board using a Hall Effect
Sensor array. Second, it provides a system for playing a social board game using shared and
private screens to represent board play and hands, respectively. The board display function
implements LED and Seven-Segment drivers in exactly the means they are meant to be, and
therefore no liability for patent infringement should exist in that area. Furthermore, the software
on the Raspberry Pi is either license-free or freely licensed, and again no risk of patent
infringement. Included are three patents which most closely resemble the functions performed by
Hackers of Catron and the actions that may need to be taken as a result of these patents.
6.1 Results of Patent and Product Search
First, the overall function of Hackers of Catron may be in violation of US Patent 8226476
B2, which was filed by Quado Media Inc. on November 4, 2009 and granted July 24, 2012[1].
This patent describes a “multi-player, multi-screens, electronic gaming platform and system”
which has a main display for showing the shared portion of the game and terminals for
displaying the private portions of the game, remarkably similar to the function of Hackers of
Catron. Specifically, the first claim calls for “a main console comprising: a monitor interface; a
user interface, a processor, a native operating system (OS)…an augmentation layer executing on
top of the native OS and providing gaming services; a game application executing on the
processor… and a communication interface enabling communication between the processor and
least one of a mobile terminal and another main console; wherein said augmentation layer is
programmed to cause the main console to transfer digital gaming objects by sending to the
monitor interface a digital gaming object…” all of which are components of the Hackers of
Catron system. Furthermore, in a later, dependent claim it states, “…wherein the main console is
configured to display shared parts of a social game, while the terminal is configured to display
private parts of the social game.”
The second patent, US Patent 5853327, was filed on February 21, 1996 by Super
Dimension, Inc. and granted on December 29, 1998[2]. This patent is for a computerized game
board that identifies pieces on a playing field and then senses the location of the piece and
“acuat[es] an audio/visual display sequence in response thereto.” It claims, “An electronic game
board system comprising; a game board surface; … a plurality of playing pieces positioned on
the game board surface, … and a plurality of sensors which… generate a plurality of sensor
signals responsive to the location of at least one playing piece for automatically and nondiscretely sensing the location of the playing pieces.” In addition it claims, “a processing unit
which receives the sensor signals and which determines the identity of the at least one playing
piece and the location of the playing piece on the game board surface based on the sensor
signals,” and “playing pieces are selectablypositionable by a player … wherein said processing
-10-
ECE 477 Final Report
Spring 2013
unit is operative to actuate an audio/visual display sequence in response to said determined
location.”
The final patent is may be too similar to Hackers of Catron’s sensing function. US Patent
5734130 was filed by IBM Inc. on August 4, 1995 and granted on March 31, 1998[3]. It
describes a system for digitizing and sensing the location of a magnet using an array of Hall
Effect Elements. Specifically, in claim 1: “a digitizer pad having a work surface, an array of Hall
effect elements (HEEs) arranged beneath said work surface in an orthogonal grid of rows and
columns with each HEE being identified by its row and column location … scanning circuitry
for scanning said array… and a user manipulable magnetic actuator for selectively actuating said
HEEs.”
No commercial products were found that were similar enough to Hackers of Catron to
warrant a possible infringement of patented technology. See the conclusion for information
regarding Catan, the game on which Hackers of Catron is based.
6.2 Analysis of Patent Liability
For each patent mentioned in the previous section, first the similarities will be compared,
then the differences, and finally a judgment will be made whether infringement exists. For US
8226476 B2, the claims which most resemble Hackers of Catron are the first claim which
basically describes the overall setup of Hackers of Catron, and the tenth claim which calls out a
system for showing shared information on a main board and private information on individual
platforms. However, although the tenth claim is spot on with Hackers of Catron, it is dependent
on the first claim, and the first claim contains many differences from the function of Hackers of
Catron. The first claim ends with “wherein said digital gaming object comprises a digital dice,
and wherein the object transfer signal comprises an indication corresponding to magnitude and
direction of force applied to the digital dice,”[7] which is a function not implemented in the
project at all. Again in the first claim, “enabling communication between the processor and at
least one of a mobile terminal and another main console;” (emphasis added). Hackers of Catron
only uses one main console. Other claims show that this patent allows for board expansion,
where this project does not. Therefore, Hackers of Catron does not infringe on this patent, either
literally or by doctrine of equivalents.
US 5853327 is similar to Hackers of Catron primarily in the second and third claims
quoted above in that the patent claims the function of identifying pieces on the board and
creating an audio/visual response to the movement of those pieces. However, although the
function is the same, the method for doing so is vastly different. The patent claims the method as
“an excitation signal generator which generates an electromagnetic query signal; … each said
piece including a transponder which receives the query signal and, in response thereto, generates
an identifying answer signal;” in claim 1[8]. This is not at all similar to Hackers of Catron’s
method of using a Hall Effect sensor grid and passive, magnetic pieces. Therefore, Hackers of
Catron is also not infringing on this patent, either literally or by doctrine of equivalents.
-11-
ECE 477 Final Report
Spring 2013
The last patent, US 5734130, is perhaps the most likely to cause an infringement. Its
claimed function, identifying the location of a magnetic actuator on a surface, is precisely one of
the main functions of Hackers of Catron. In addition, its method of using an array of Hall Effect
Elements is also similar to the project’s method. There are some technical differences, though,
that may make Hackers of Catron different enough not to infringe. First, the patent claims that
connected to the HEEs is “a plurality of differential amplifiers, each amplifier being connected to
a different HEE for receiving said Hall effect voltage there from, each differential amplifier
producing an output signal proportional to said Hall effect voltage produced by said
HEE… and trigger means connected to each of said differential amplifiers for producing digital
outputs indicating when said voltages from said differential amplifiers are above a
predetermined magnitude.”[9](emphasis added) What this means is that the HEEs used in the
patent are analog devices that must be amplified and connected to gates to digitize them, whereas
Hackers of Catron uses Hall Effect sensors that already have built-in digital outputs.
Furthermore, the scanning circuitry claimed is like that of a keypad, while Hackers of Catron
uses a multiplexer array to retrieve the status of the Hall Effect sensors. And as a small note the
sensor array is specifically claimed to be in “an orthogonal grid of rows and columns” while the
sensors in the project are only in rows in columns in a logical sense, not physically. Because of
these differences, there is no literal infringement on this patent. There may, however, be room to
argue that there is infringement based on the doctrine of equivalents.
6.3 Action Recommended
Based on the analysis of the previous section, no action need be taken for the first two
patents as there just is not enough overlap in similarities to justify a case for infringement. For
the third patent, supposing that infringement is claimed under the doctrine of equivalents, there is
a simple, if perhaps unorthodox solution: wait two years for the patent to expire. However, if this
project were a real product, two years may not be a financially responsible time frame to wait for
a patent to expire, as competitors may beat the product to market. Other solutions could include
changing the sensing method to a capacitive sensor (although the scope of patents for capacitive
grids is perhaps even more diverse than for Hall Effect arrays) or using straight keypad-like
switches since these are not patented (but the challenge of making this grid sensitive enough to
detect the pieces is also daunting). Finally, as a last resort, a licensing agreement could be
reached for the two years that the patent would remain valid.
6.4 Summary
This initial patent analysis is promising, as it seems to indicate that there are no current
patents on the type of system Hackers of Catron is: a single-purpose, wifi-enabled, electronic
board game. However, the analysis is neither exhaustive nor authoritative, and further
examination may show this analysis woefully incomplete.
-12-
ECE 477 Final Report
Spring 2013
If Hackers of Catron were to be taken to market, perhaps a greater concern than patent
liability is copyright infringement. It is based on a game called Settlers of Catan. Catan GmbH,
the owner of the relevant copyrights, is known to be relentless in enforcing its copyrights.
Therefore selling the idea to Catan GmbH may be more feasible than taking the product to
market on its own.
-13-
ECE 477 Final Report
Spring 2013
7.0 Reliability and Safety Analysis
The Hackers of Catron utilizes a large PCB design which accommodates 145 Hall Effect
sensors for piece detection, 38 RGB LEDs for displaying of resources and 19 two-digit seven
segment displays to signify rarity. The failure of any one of these components is very likely, so
special considerations must be taken to troubleshoot and identify faulty components.
Additionally, the large selection of components draws a significant amount of current, which is
almost to our power supply’s limit.
Safety issues include power supply failures which may catch fire, and the potential for all
the LEDs to rapidly blink, especially in the case of an unstable power supply. Power supply
failures are likely considering the 3.3V line is at its limit in current draw from the seven
segments. Users who are prone to epileptic seizures could be harmed by the unintentional
blinking of LEDs and should likely not play this game.
7.1 Reliability Analysis
Components in this design selected to be most likely to fail are the LM2675M Voltage
Regulator, AT32UC3B Microcontroller, Omron W2RV004RM RGB Driver, and the AS1116 7
Segment Driver. The LM2675M Voltage Regulator was selected because it runs hot and must be
able to switch very rapidly to produce the 3.3V power supply. The Omron RGB Driver was
selected since each channel is sinking current from two LED RGBs and has the potential to sink
more current than recommended in the data sheet. The AS1116 7 Segment driver is selected
because it is a complex component and we are having many problems with it currently.
7.1.1 Models and Assumptions
The model used to determine the failure rate was found in the Military Handbook
(MIL-HDBK-217f) [10]:
λP = (C1 πT + C2 πE)πQπL
And mean time to failure (MTTF) in years:
MTTF = 8765.81 / λP
For this analysis, it is assumed that the component quality factor (πQ) is 10 for
commercial components. This is quite a conservative assumption, especially when many
commercial products at this time are being manufactured at close to military quality. All of the
components we are using have been out for more than two years, so the learning factor (πL) that
-14-
ECE 477 Final Report
Spring 2013
will be used is 1. The environmental coefficient (πE) is 2.0 for ground, fixed (GF). The fixed
environment was selected over the mobile environment since the description of ground, mobile
seemed to be referring more towards motor vehicles while our board will be largely stationary
during play.
For the microcontroller, the die complexity coefficient was determined to be 0.56 based
on the Military Handbook, since it is 32-bit. The temperature πT coefficient is 0.98 since it is a
digital MOS microcircuit and its max recommended temperature is 85 C. The packaging failure
C2 coefficient is 0.032 since our micro has 64 pins and is a surface mount device. By this
analysis, the failure rate for the microcontroller is 6.128 failures per million hours.. The mean
time to failure is 18.6 years.
For the voltage regulator, the best fit in the military handbook appeared to be the
microcircuit section. At an estimated 101 to 300 linear MOSFETs, the regulator would have a
die complexity coefficient of 0.02. The temperature factor for this device, assuming the
temperature does not go about 100 C, is 16. The packaging failure coefficient is 0.0072 since it
has 16 pins and is a surface mount device. The failure rate for this device is 3.34 failures per
million hours. The mean time to failure is 34.1 years.
For the RGB driver, the best fit in the military handbook appeared to be the microcircuit
section. At an estimated 3001 to 10000 gates, the RGB driver would have a die complexity
coefficient of 0.08. The temperature factor for this device operating at the maximum 85 C is
0.98. The packaging failure coefficient is 0.013 with a 28 pin SMD package. The failure rate for
this device is 1.044. The mean time to failure is 109.3 years.
For the 7 segment driver, the best fit in the military handbook appeared to be the
microcircuit section. At an estimated 3001 to 10000 gates, the 7 segment driver would have a
die complexity coefficient of 0.08. The temperature factor for this device operating at the
maximum 85 C is 0.98. The packaging failure coefficient is 0.011 with a 28 pin SMD package.
The failure rate for this device is 1.004. The mean time to failure is 123.6 years.
7.1.2 Failure Rate and MTTF Analysis
Atmel AT32UC3B Microcontroller [11]
Parameter name
Description
Value
Comments
C1
Die complexity
0.56
32-bit microcontroller
πT
Temperature coeff.
0.98
operating at 85 C
C2
Packaging Failure
coeff.
0.032
64-pin SMD
πE
Environmental Factor
2.0
Ground, fixed
-15-
ECE 477 Final Report
Spring 2013
πQ
Quality Factor
10.0
Commercial part
πL
Learning Factor
1.0
> 2 years
λP
Failure Rate
6.128
failures per million hours
MTTF
with 1 micro on board
18.6 years
LM2675M Voltage Regulator [12]
Parameter name
Description
Value
Comments
C1
Die complexity
0.02
101 - 300 linear gates
πT
Temperature coeff.
16
operating at < 100C
C2
Packaging Failure
coeff.
0.0072
16-pin SMD
πE
Environmental Factor
2.0
Ground, fixed
πQ
Quality Factor
10.0
Commercial part
πL
Learning Factor
1.0
> 2 years
λP
Failure Rate
3.344
failures per million hours
MTTF
1 Buck on board
34.1 years
Omron W2RV004RM RGB LED Driver [1]
Parameter name
Description
Value
Comments
C1
Die complexity
0.08
3001-10000 digital gates
πT
Temperature coeff.
0.98
operating at 85 C
C2
Packaging Failure
coeff.
0.013
28-pin SMD
πE
Environmental Factor
2.0
Ground, fixed
πQ
Quality Factor
10.0
Commercial part
πL
Learning Factor
1.0
> 2 years
-16-
ECE 477 Final Report
Spring 2013
λP
Failure Rate
1.044
MTTF
with 6 Drivers on
board
109.3 years
failures per million hours
AS1116 7 Segment Driver [2]
Parameter name
Description
Value
Comments
C1
Die complexity
0.08
3001-10000 digital gates
πT
Temperature coeff.
0.98
operating at 85 C
C2
Packaging Failure
coeff.
0.011
28-pin SMD
πE
Environmental Factor
2.0
Ground, fixed
πQ
Quality Factor
10.0
Commercial part
πL
Learning Factor
1.0
> 2 years
λP
Failure Rate
1.004
failures per million hours
MTTF
with 5 drivers on board 123.6 years
As a whole, most of the components chosen for this analysis do not meet the desired
reliability requirements. Being responsible for medium and high critical failure modes, the
LM2675 voltage regular especially exceeds a failure rate of 10-9 and has a MTTF of 34 years.
This is not good enough for a part that can cause harm to the user or damage the entire board. To
remedy this issue, some kind of watchdog can be implemented to watch the 3.3V line. When the
line becomes unstable, it could shut down the power supply before it brings harm to users or the
board.
The other 3 components, the microcontroller, RGB drivers, and 7 segment drivers, where
chosen because they are the most complex components on the board and prone to failure. The
failure rate of these devices exceeds 10-6 which is a higher failure rate than expected. This may
be due partly to the conservative analysis of the failure rate. Some additional fail safes may
needed if this product was to enter the market.
7.2 FMECA
The schematic for The Hackers of Catron can be divided into five subsections. These
subsystems are the power supply, Hall Effect sensor network, RGB LED display, seven segment
-17-
ECE 477 Final Report
Spring 2013
display, and microcontroller. Failure modes for the power supply include low 3.3 voltage, high
3.3 voltage, unstable 3.3 voltage, and unstable 5.0 Voltage on the board. The high 3.3 voltage is
a high critical failure, meaning an overheated voltage regular could ignite and cause harm to the
user. The other power supply failure modes are medium critical, since they have the potential to
damage other components on the board.
For the Hall Effect sensor network, failure modes relate to the misdetection of pieces. A
failure in this subsystem could lead to positions on the board being unusable or the game to get
trapped in an error state for detecting an illegal piece. This could be due to Hall Effect sensors
output that is always on or off, or adjacent sensors triggering each other. In order to simplify the
detection of these failures, a troubleshooting test sequence can be run to verify that all sensors on
the board are working properly.
For the RGB LED display, failure modes result in the incorrect display of LEDs, either
turning them off, on, or flickering incorrectly. This occurs when the RGB driver channel is not
modulating or the RGB driver registers reset unexpectedly.
The Rarity display failures are observed when 7 segments do not turn on or certain segments
are not being displayed. This happens when the 7 Segment drivers are not switching between
digits or latching new data. Additionally, the displays could have burned out segments.
When the microcontroller behaves unexpectedly, it is often because the reset is incorrectly
triggered and the board has been reset. Also, it sometimes stops executing instructions which
happens when the external oscillator is damaged or the power is too noisy for the micro to
receive a clear signal from the oscillator.
7.2.1 Levels of Criticality
Various levels of criticality are used to differentiate which failure modes should have a
lower failure rate, and which failure modes are less disastrous. On one end, there is ‘low’
criticality which specifies that the failure mode is not harmful to the user or destructive of the
rest of the board. For instance, sensor or communication failures would fall into this category.
The product may still be unusable until the part is replaced. Low critically errors are intended to
have a failure rate of 10-6 or less.
‘Medium’ criticality is defined as a failure that does not harm the user, but has a potential
to damage the system. A failure in the power system could be medium criticality since it has the
potential to damage the entire board. Medium criticality failures are aimed to have a failure rate
of 10-7 or less.
‘High’ criticality is reserved for failures that present potential harm to the user. Related
failures for this project would be the voltage regulator catching fire, or the RGB LEDs producing
a strobing effect that could induce an epileptic seizure. While highly unlikely, it is still a
possibility. High critical errors should only occur with a failure rate of 10-9 or less.
-18-
ECE 477 Final Report
Spring 2013
7.2.2 Observation Techniques
In order for the user to troubleshoot problems with the board, observation will not be
enough. The board itself has 145 Hall Effect sensors and 39 7 segment displays that would need
to be verified. In order to aid in this process, the game could include a troubleshooting option
which runs a sequence to check for proper Hall Effect sensor behavior and burned out seven
segment displays. The Hall Effect sensor test in its current state has the player go around the
board to each position and lights up the corresponding hex RGBs and uses an error code on the
seven segment display to point to the correct position. If the board does not react, the sensor
may be dead or disconnected, and if multiple positions respond, there may be a short between the
Hall Effect outputs.
7.3 Reliability and Safety Summary
In conclusion, reliability is an issue that The Hackers of Catron may struggle with
should it ever be produced for the market. Since it requires such a vast array of components to
operate, the likelihood that any one of them could fail is very high. Additionally, the game in its
current state draws almost all of the power the voltage regulator is supplying. In a revision of
this design, the power would be amped up for both the 5.0 and 3.3 V power supplies. As it is
now, the board has occasional issues with too much switching on the lines creating excess much
noise or drawing additional current and shutting the entire board down. The reliability of the
crucial components: the voltage regulator, microcontroller, and drivers, are not up to acceptable
failure rates. Some additional safeguards may need to be implemented or high grade
components chosen for a revised design. In order to validate the functionality of 145 Hall Effect
Sensors and 19 seven segment displays, special troubleshooting routines can be run to identify
failures. It can be a challenge to ensure the reliability of such a large PCB with so many
components.
-19-
ECE 477 Final Report
Spring 2013
8.0 Ethical and Environmental Impact Analysis
The electronic version of this game is built using a large printed circuit board and several
other components which react to magnets and is housed in an acrylic package. As one might
imagine, there are a few environmental concerns to be dealt with, not to mention the ethical
implications of some of the components and of the environmental concerns themselves. While
the product should last a relatively long time, as there are few moving parts and it requires very
little maintenance, it will still likely need to be disposed of at some point, and some special
considerations come into play there.
8.1 Environmental Impact Analysis
The obvious first concern for any device is the creation of the device itself. In the case of the
Hackers of Catron, there is a large printed circuit board along with several electronic components
which have special considerations. Additionally, the packaging and the pieces themselves should
be considered.
The printed circuit board is an obvious source of concern to anyone familiar with how they
are made [13]. The board requires the use of various hazardous materials that are not easy to
dispose of in any way [14]. Ideally, these would be reused as much as possible, but considering
that these chemicals have a limited number of times they can be reused, they will need to be
disposed of at some point. Reducing the use of the chemicals may help. In order to reduce the
use of the chemicals, we could shrink the size of the PCB some or re-design the board such that
it does not use a large PCB, but uses a small one with some interconnecting wire or something of
the sort connecting to the Hall Effect sensors, LEDs, and the like. This has other technical issues
but those are outside the scope of this report. The use of some of these chemicals will be
necessary no matter what we do, but reducing their use can help with environmental concerns.
The printed circuit board isn’t the only electronic component we need to worry about,
however. Many of the integrated circuits on the device, such as the microcontroller and the
drivers, are manufactured using similarly environmentally unfriendly processes [5].
Unfortunately, the only real way to alleviate this would be to go to another manufacturer or try to
convince the manufacturer of the chips to change their manufacturing process. Considering the
majority of manufacturers use similar processes, there is little that can be done. It may be
possible to minimize the use of these devices by redesigning the board, but other than selecting
manufacturers carefully and completely redesigning, there is little else to be done.
As far as the packaging is concerned, acrylic, abs, metal, and wood are the primary
components. Wood, given it comes from environmentally sustainable wood, is not a concern.
Acrylic and ABS are the biggest concerns. The ABS could be replaced with corn-based PLA,
which could possibly increase costs but be much more sustainable and biodegradable [6][7].
Acrylic is derived from petroleum, a fossil fuel, which is generally regarded as being
-20-
ECE 477 Final Report
Spring 2013
environmentally unfriendly [15]. The best option for this would be to use as much recycled
plastic as possible.
Everything to now only considers the manufacture of the device, however. While
general use is not a concern outside of power usage, as the device has no moving parts and
requires little maintenance, disposal of the device in its current form could be a challenge to a
user. There are several pieces to consider, including the PCB, the packaging, and other
electronics not mentioned to this point, such as the Raspberry Pi.
The circuit board and the electronics on the board are the most obvious concern. PCBs
are not inherently biodegradable, and there is little that can be done about that. The best way to
dispose of the circuit board would be to send the device to an electronics recycler. As e-waste is
becoming more of a concern in the mind of the average, moderately well-educated citizen, there
are more recycling centers popping up in relatively well-populated areas, and there are website
such as 1800recycling.com that can assist users in their search [20]. The user manual can
advertise one of these sites. Additionally, if the product is being manufactured, the manufacturer
can receive products from users and send them off to an appropriate electronics recycler after
harvesting any parts that could be used for a refurbished device.
In addition to the electronics and the PCB, we are using a Raspberry Pi as a web
server, which is an independent device of its own. The pi has its own concerns, however as the pi
should not fail sooner than the primary PCB, it can likely be used in refurbished versions of the
device if it were sent back to the manufacturer, or even harvested by the user for their own use. If
the pi were to fail, it is unlikely that the SD Card that the pi runs off of would fail, so at the very
least that could be reused. If it were to be disposed, it would need to be disposed in a similar way
to the PCB itself, going through an electronics recycler. Of course, in order to connect the
Raspberry Pi to the PCB, there are a few wires, but these can be reused or will be taken care of
by the electronics recycler.
Outside of the board itself, there are also the pieces and the packaging. As far as the
pieces go, they are made of wood with magnets glued to them. The magnets must be disposed of
in a very particular way – in many places there are specific requirements, but usually it is safe to
put them in a metallic box to dispose of them [21]. They can also be re-used if they are still
magnetic, or if not, the metal may be able to be reclaimed. Generally, if the device is sent to an
electronics recycler, the pieces should be as well, and the recycler will be able to take care of the
magnets. The wooden parts of the pieces are biodegradable, and can be reused in various ways.
If they are in decent condition when returned to the manufacturer, they can even be reused in
refurbished products.
The packaging is a large concern as well. The device is contained in a large, acrylic
hexagon box. The box is held together with acrylic glue. Additionally, there are ABS hexagons
and washers glued to the top of the box, and hinges glued to the bottom. None of these things are
biodegradable by any stretch of the imagination, however they are recyclable and reusable [16]
[18]. The packaging can be recycled separately from the electronics at a standard recycling plant,
as the glue should be removable with a specific compound. Of course, the compound may not be
-21-
ECE 477 Final Report
Spring 2013
environmentally friendly itself, so it would also need to be disposed of properly. When all the
pieces are separated, all of the metal and plastic can be reclaimed. If sent back to the
manufacturer, it could even be refurbished. Should the ABS be replaced with PLA, it would be
biodegradable and easy to simply throw away [19]. If the user opted to keep the packaging, it
could make a nice flower bed.
Even with all these nice things that can be done with the product, there is nothing
stopping the consumer from taking the easy route and just throwing the device away. That can be
deterred to some extent by placing appropriate warnings in the user manual, or by offering an
incentive to consumers who ship the device back for recycling, such as offering 20% off their
next purchase from the manufacturer or something to that effect.
8.2 Ethical Challenges
Ethically, there isn’t much that can go wrong with the product, but there is always the
possibility for concern. The device itself is quite large and cumbersome, and there are lots of
small pieces that could post safety risks, for example. Additionally, there is a security risk
involved with the Raspberry Pi. Generally, these cannot be mitigated, but proper warning and
usage can reduce the chance of anything unfortunate happening.
Starting with the obvious, the device is electronic. Most electronic devices have the
possibility for electric shock and burn, just from being there, as there is the possibility of a
malfunction on the device which could cause a dangerous situation. For this situation, it would
be best to have appropriate voltage and current ratings printed on the board near the power
connector, along with a safety warning nearby warning not to poke around in the device for the
same reasons.
On top of the electrical concerns, there are concerns with the size of the device and with
the small pieces. The device should not be marketed to people under 14 years of age due to the
magnets, and appropriate safety warnings in the user manual should note that there are small
pieces with the device and they should not be anywhere near children. There are also pinch
hazards that go along with magnets, and of course concerns with carrying the physical device, so
there should be warnings to have the device on a balanced surface and to be careful when
picking up and moving the device. The magnets can be stored on a metal plate with beveled or
plastic-coated edges that can be shipped with the device, if it were to go to market.
The device has a large number of LEDs, and if the device is used improperly or if the device
malfunctions, they could flash at a high frequency and cause seizures in photosensitive
individuals with epileptic tendencies. In order to help reduce the likelihood of this scenario
occurring, the best option would be yet another warning in the user manual and on the device
itself warning of the effects of high frequency strobe lights on such individuals.
There are also concerns with security when the Raspberry Pi is brought into the
picture. Because the Raspberry Pi is running an open Wi-Fi Access Point, sensitive information
should not be transmitted over it. Generally this should not be a concern when the device is not
-22-
ECE 477 Final Report
Spring 2013
attached to an external network, as there is nothing other than the web interface for the device
that can be accessed. However, if the device is connected to a network, then the possibility exists
for a device in promiscuous mode not connected to the Pi to sniff traffic and obtain sensitive
information. In order to warn the user, there should be a user manual warning and a warning
upon connection to the device. Additionally, a future iteration of the product could include the
capability to set up a WPA or WEP encrypted network. While using a network encrypted in this
way does not mitigate all risk, it does reduce it greatly [22].
Finally there is the concern with overuse of the device. If the device is used for long
periods of time, it could be unhealthy for the players and possibly harmful for the device. A brief
warning in the user manual to take breaks from the game every few hours would likely be
sufficient in mitigating this risk, though more extreme measures such as turning the device off
after a set period of time could completely remove this risk.
8.3 Ethical and Environmental Impact Summary
The Hackers of Catron will be an incredibly fun game, but through its lifecycle there are a
few reasonable concerns. Manufacturing involves some nasty chemicals and methods that may
not be completely safe for the environment. Additionally, the product is essentially one giant
PCB wrapped in plastic with a bunch of small pieces, so disposal is not easy either. The best way
to dispose of the game would be to recycle it, of course, but in order to ensure the consumer does
so there may need to be some sort of incentive to do so. Even outside of the environmental
concerns, there are ethical concerns with safety and security. Many of the safety concerns are
similar to most other electronic devices and magnetic pieces on the market. The security
concerns could be slightly reduced if proper encryption were added to the wireless network, but
using a wireless network is inherently less safe than using a wired network, so the concerns will
never be resolved. Ideally, many of the safety and security concerns could be mitigated using lots
of warning labels.
-23-
ECE 477 Final Report
Spring 2013
9.0 Packaging Design Considerations
While the economy is handled via a web server, most of the game takes place on a
physical game board. Catan is composed of nineteen hexagons which fit together to make up the
board. Rather than making the players build this board themselves, simply turning on the game
can randomize the playing surface. To accomplish this, each hexagon will use LEDs to
designate its resource type. The LEDs are mounted to the surface of the PCB, and a sheet of
frosted acrylic is placed above to disperse the light. Dividers will be used to represent the
borders and separate the light between the hexagons. Hall Effects will be mounted to the surface
of the PCB for the purpose of detecting the magnetic game pieces. It is important that the
distance between the PCB and frosted acrylic is optimized such that the pieces are easy enough
to detect without interfering with adjacent sensors.
The board also requires space beneath the PCB in order to house the Raspberry Pi,
power supply, and pieces. The side panel will include manual buttons and switches to turn the
game on/off, reset, and other functions we may realize we need in the future.
9.1 Commercial Product Packaging
In this section, two commercial products are analyzed for positive aspects and whether
their beneficial features can be implemented in our design. The designs selected are Dungeons &
Dragons Computer Labyrinth Game and The Generals. Unfortunately, these games do not have a
strong resemblance to ours since neither implements a board lit by LEDs or proper piece sensing.
Finding a board game with either of these qualities proved to be quite difficult.
9.1.1 Commercial Product #1 - Dungeons & Dragons Computer Labyrinth
Figure 7-1: Dungeons & Dragons in Play (left) and in Storage (right)
The Dungeons and Dragons Computer Labyrinth game consists of a board for several
creature pieces, players, and walls [23]. This is comparable to our board in that we place road
pieces around the borders of the tiles.
-24-
ECE 477 Final Report
Spring 2013
There are many positive aspects to this packaging design that could be used for our
project. First of all, the game pieces fit neatly inside a tray which slides in and out of the
package. This idea is planned to be implemented in our own design by having an opening side to
store a small container full of game pieces underneath the PCB. Also, the D&D package
incorporates a grid where wall pieces can snuggly snap in, as well as indentations for the other
pieces. This would be a great feature for our road pieces. Unfortunately, without access to
plastic molding, it may make our design too complicated to implement. If we can find access to
a tool that can cleanly cut indents into the acrylic, it would be great to have depressions for our
pieces to prevent slipping and sliding during play. Finally, this design incorporates space along
the edge for auxiliary buttons. It would be useful for our project to have power, reset buttons,
and dice roll display along the edge of the board. This may be taken into consideration later, but
for now our design will place these features on the side of the package.
Negative aspects of this package include having to manually press each tile and the use of
plastic molds. Our design uses Hall Effect sensors such that pieces can be detected without
physically pressing buttons. This implementation is much closer to the natural way of play. The
surface of the board also has a very claustrophobic and cluttered feel.
Our project is unique in that each tile will be lit by an LED projecting into frosted acrylic.
This is for the purpose of identifying each tile’s resource and allows the game to randomize the
placement of these resources. Pieces can be placed along the edges, corners, and center of these
tiles. Each tile is a hexagon rather than square shape. As a whole, Dungeons and Dragons uses a
pretty effective packaging scheme with several features that we may try to emulate.
9.1.2 Commercial Product #2 - The Generals Electronic Strategy Game
Figure 7-2: Initial Setup of The Generals
The Generals is a strategic game like chess or Stratego [24]. It is similar to our package
since it uses a flat grid surface to maintain pieces and electronics examine piece movement.
The positive aspects of this package are its sleek clutter-free design, thin board, and ease
of construction. We will also use a minimalistic approach for our design. Our board uses a
-25-
ECE 477 Final Report
Spring 2013
similar simplistic flat surface made from a sheet of frosted acrylic. This will make construction
easier and lend an overall appealing look. The thin board is not an option since we need space
below the PCB for the raspberry pi. A simple design like this would be much easier to construct
from basic materials and tools.
The negative aspects of this package are there is no way to keep the pieces from sliding,
no internal storage, and lack of durability. Our design intends to use depressions in the acrylic if
possible to help keep pieces from sliding. The sides and base will be made from wood to ensure
durability of the board.
As a whole, The Generals packaging design is pretty dissimilar from our own but its
simplistic approach can be emulated by our design.
9.2 Project Packaging Specifications
The following constraints must be met for the package design to be successful. These
constraints will dictate the packaging specifications. First of all, a large, flat playing surface is
required. This will ensure that the hall effect sensors have enough distance between them in
order to correctly differentiate between pieces and reduce piece detection false positives. This
will also ensure that our board can accommodate the size of our physical playing pieces. The
design must also have a short distance between the PCB and playing surface. The Hall Effect
sensors have a range of about 1.2 cm (or ½ inch) for our chosen magnets. This constraint must be
met if we wish to accurately detect the pieces. We must also have a semi-transparent playing
surface. The game uses RGB LEDs under each tile to signify the type of resource that the tile
has [1]. The surface should allow LEDs to shine through and disperse light while still obscuring
the view the PCB below. Additionally, the design requires opaque dividers between the resource
tiles. This will reduce bleeding of the LED light between tiles. Finally, we will need some
additional space underneath the main playing surface. This space will contain the raspberry pi
and also a storage chest for the game pieces.
The design will use a hexagon shaped board which is about 2 ½ inches thick. This will
allow plenty of space for the raspberry pi and game pieces. The PCB will be cut into a hexagon
shape and sit on a shelf about ½ inch below the surface. The surface will be cut from a 0.118
inch sheet of frosted acrylic [27]. Below the surface we will use several plastic white dividers to
separate the tiles. These dividers will be tall enough to occupy the space between the PCB and
acrylic surface. The space will be constrained by both the Hall Effect sensor range and the
height of the 7 segment displays. The exterior of the design will be made by cutting pieces from
a thick sheet of acrylic or some other plastic.
One of the sides will be mounted on a hinge so that the board can be opened. This will
allow access to the pi where a monitor, keyboard, etc can be plugged in for easy debug. Also the
base of the PCB will be exposed, and headers should be available to plug into and reprogram the
micro. The PCB and acrylic surface can be lifted off of the sides so that we can go back and
-26-
ECE 477 Final Report
Spring 2013
solder a faulty connection or flywire a broken section. The side of the board will have several
cuts for a barrel DC power supply, on/off roller switch, and a reset pushbutton.
9.3 PCB Footprint Layout
This section explains the choices for the selected footprint choices most appropriate
for the design. Each of these choices was printed to scale and tested to fit with our physical
components.
The Atmel AT32UC3B064 microcontroller is available in several TQFP and QFN
packages [11]. I selected the TQFP64 footprint from the atmel.lbr library since our
microcontroller is surface mount and TQFP uses leads, making it much easier to solder.
The Austriamicrosystems AS1116 7 Segment Driver fits the QSOP24 footprint from the
maxim.lbr library [2]. This driver is also available in TQFN but we figured that a narrower chip
would be easier to route on the PCB and easier to solder since we only have to line up two sides.
The Omron W2RF004RM RGB LED Driver uses a TQFP26 package [1]. The footprint
was custom designed since a footprint with the same characteristics could not be located in the
eagle libraries. The TCS20DLR Toshiba Hall Effect Sensor uses an SOT-23 package which was
also custom designed.
The Kingbright DC56-11EWA 2 Digit 7 Segment comes only in a through hole
package called DA56 [25]. This footprint was easily found in the display-kingbright.lbr library.
The Cree® PLCC4 3 in 1 SMD LED comes in a PLCC-4 Package [26]. The P-LCC-4-3
footprint was selected from the led.lbr library since it is designed for an RGB led and fits the
dimensions. It should be noted that the pad numbering is different from what is given in the
LED datasheet and the footprint should possibly be modified to prevent confusion.
The PCB size requirements depend on the size of an actual Catan board. Since our
design intends to be of the same dimensions or slightly smaller than a regular Catan board, the
dimensions of the PCB can be calculated using the hex tile dimensions. The size of a Catan
board is 15.625 in x 14.875 in (400 mm x 380 mm). The area is approximately 232 in2 (152000
mm2).
9.4 Packaging Design Summary
In summary, the packaging design must meet certain requirements in order for our game
to be playable. It must have a thin enough surface to detect pieces. The surface must be big
enough for the sensors to differentiate between pieces on the board. The surface itself must be
translucent in order for the LED light to disperse. These constraints dictate that our board must
resemble a design similar to that in appendix B. There are still a few aspects that could end up
modified as the design runs its course, but these core criteria must always be met.
-27-
ECE 477 Final Report
Spring 2013
10.0 Schematic Design Considerations
The display of board setup requires that each hexagon (hex) be recognizable as one of the
five resource types or the desert and must be associated with a rarity that corresponds to a
possible sum of two thrown dice. In order to accomplish this, the design utilizes a combination of
RGB LEDs to designate resource types and two-digit seven-segment displays to designate the
rarities. In order to sense the position of all the pieces the design uses a grid of Hall Effect
sensors which indicate when a magnet has been placed above them.
10.1 Theory of Operation
The Hackers of Catron circuit comprises three major functional subsections: The Hall
Effect sensor array, the RGB LED array, and the seven-segment display array. In addition there
are several minor functional subsections including the power supply, the Raspberry Pi interface,
and an additional Hall Effect sensor which did not fit in the array. Across all subsections, all ICs
are powered by the 3.3V supply rail, chosen primarily to eliminate the need for voltage level
translation since the Hall Effect sensors and microcontroller (MCU) both operate at 3.3V
[11][28]. The operating mode and conditions for each functional block are summarized at the
end of this section.
The purpose of the Hall Effect sensor array is to sense the presence and position of
pieces placed on the playing surface.The presence of a piece is indicated by the output of a Hall
Effect sensor.The position of the piece can be determined by correlating each sensor to a
physical position (implemented in MCU code).To save pins, sensors are grouped into 18
“columns” of 8 “rows” each. The MCU can access any row of 18 sensors by outputting the
correct address on 3 select pins of discrete multiplexers into which each column is fed.
The RGB LED array is designed to represent a hex’s resource type with unique, distinguishable
colors. The array will also be used as feedback during game play to indicate improper piece
placement or piece placement confirmation as needed. In order to control the color and
brightness of the RGBs, the MCU sends commands via a two-wire interface to 7 nine-channel
LED driver chips. The driver chips can communicate at up to 5MHz [1], so there should be no
issues with updating the state of the RGBs quickly. The driver chips also have their own data line
buffers, echoing the data and clock lines on a pair of output pins, so the chips will be daisychained together. The LED control outputs are open-drain, which allows the LEDs themselves to
be powered by the 5V rail. This is done because the green and blue LEDs have typical forward
voltages of 3.2V and up to 4.0V [2], making it unfeasible to drive them with the 3.3V rail.
Furthermore, each channel will control two LED’s in parallel in order to increase light coverage
on each hex.
The seven-segment display array is used to represent the relative rarity of each hex.
Since the possible value for each hex can go up to 12, two digits are required for each hex,
-28-
ECE 477 Final Report
Spring 2013
making a total of 38 digits. To control all these seven-segment displays, the MCU uses SPI to
shift control data to 5 eight-digit control chips. Each chip requires a load-enable or slave-select
line to be driven low in order to accept control data, but will also shift out control data as long as
the load-enable line is not driven high again[26]. This allows the MCU to shift data into all 5
chips at once while only using one load-enable line. The chips are connected to both the anode
and cathodes of each digit, and only a single resistor is required to set the current for each
segment.
In order for players of Hackers of Catron to user their mobile devices to play the
game, a Raspberry Pi acts as a server and a wireless access point. To retrieve the status of the
game and communicate the state of the economy back to the MCU, several data lines must be
used. I2C is supported by both the MCU [11] and the Raspberry Pi, so only two lines are required
to connect the two devices. However, because the Raspberry Pi already has a 26 pin header, for
simplicity the PCB will also feature a 26 pin header, to which any pins not assigned tasks will be
routed. The Raspberry Pi is powered by 5V unregulated and uses a USB interface to get this
power.
The board requires two voltage rails. The RGB LEDs and the Raspberry Pi are
powered by 5V unregulated, while everything else is powered by 3.3V regulated power.
Therefore, a simple 5V AC adaptor is used to draw power from a typical AC outlet. This is then
regulated down to 3.3V to power the more sensitive ICs on the board. In order to protect the rest
of the board during construction and testing, several jumpers are used to isolate the power supply
and the regulator from everything else.
Table 10-1 Operating Mode Summary
Subsection
Component
Function
Operation
Sensor
Hall Effect sensor
Detect piece
3.3V, active low, open
drain, .47uF bypass cap,
15kΩ Pull up resistor
Multiplexer
RGB
RGB LED
Organize sensors, reduce pin
3.3V, complemented output,
count
3 SEL lines, 8:1
Distinguish hex resources
5V, 15-20mA, parallel,
common anode
9CH LED driver
Control RGB color
3.3V, open drain,
Input: 1 data, 1 clock line
Output: 1 data, 1 clock
7Segment
2digit 7seg display
Display resource rarity
3.3V, 20mA/segment
8digit driver
Control 7seg display
3.3V, 160mA/digit, SPI
-29-
ECE 477 Final Report
Spring 2013
Input: 1 data line, 1 loadenable, 1 clock
Output: 1 data line
10.2 Hardware Design Narrative
To communicate and coordinate all the major subsections of the circuit, the MCU utilizes
the SPI, I2C, and general purpose subsystems. Port selection was done on a restrictive-first basis,
so that subsystems with the least flexibility in pin selection were assigned pins first.
I2C is used to communicate with the Raspberry Pi. The I2C subsystem is a part of the MCU’s
Two Wire Interface (TWI) subsystem. Since the TWI interface only has one choice for its pin, it
was given a pin assignment first. SPI, used to communicate with the seven-segment display
array, was the next most restrictive subsystem. This pin assignment was made so that all four
pins used are physically close to each other (see Appendix B), which should simplify routing.
To drive the select line of all 18 multiplexers present in the sensor array subsection, three of the
MCU’s four high-drive pins were chosen as address lines. Although the 1mA driving capability
of any GPIO pin should be sufficient, having the capability to drive 4mA on the high-drive pins
may prove beneficial in the future. The 18 return lines from the multiplexers along with the
output of the solitary Hall Effect sensor are assigned to the remaining pins on Port A. Finally, the
two pins used to communicate with the nine-channel LED drivers were assigned to two pins next
to each other on Port B.
There were several pins unavailable for assignment, including PortA pins 0-2 for
JTAG programming requirements. Any pin left unassigned will be routed to a header pin for
debug or communication with the Raspberry Pi. Furthermore, all communication signals are
routed to the header pin for debugging during fabrication.
The MCU can be powered with single or dual power supplies. All IO pins and the
analog subsection are powered by 3.3V, while the core and PLL are powered by 1.8V. We
decided to utilize the MCU’s internal voltage regulator to supply the 1.8V from the 3.3V rail. For
this to work 3.3V must be attached to the VDDIN pin and the VDDOUT pin must be routed to
the VDDCORE and VDDPLL pins. In order to avoid supply rail ripples, bypass capacitors are
required on both the 3.3V and 1.8V lines. Because our design does not utilize any analog
functions, the ADVREF pin is tied to ground in order to save power, as recommended by the
MCU’s datasheet.
Table 10-2 Port Assignment
Ports
Subsystem
Function
PA09, 10
TWI
Raspberry Pi communication
PA14...16, 28
SPI
Control 7seg display
PA20...22
GPIO
Select address lines for sensor array
-30-
ECE 477 Final Report
Spring 2013
PA03...08, 11...13, 17...19, 23...27, 30, 31 GPIO
Sensor array return lines
PB10, 11
GPIO
Control RGB display
RESET_N, VDDIO, TCK, PA00...02
On-Chip Debug
Programming via JTAG interface
10.3 Summary
The Hackers of Catron circuit must accomplish 4 basic tasks: sense pieces, display a
playing board, facilitate trading, and provide enough power to accomplish the first three tasks.
The first two tasks are accomplished via arrays of sensors and LEDs controlled by a string of
drivers. The third task requires a communication protocol between the Raspberry Pi and the
MCU which is fulfilled with I2C. All power will be provided by a 5V unregulated supply
regulated down to 3.3V for the CMOS devices.
The MCU interface is primarily concerned with serial communication to other devices.
The only exception is the sensor array, which uses 3 address lines to select the row of 18 sensors
the MCU will read.
-31-
ECE 477 Final Report
Spring 2013
11.0 PCB Layout Design Considerations
There are many special considerations that need to be taken into account for the PCB
layout of the project. First, due to the massive number of Hall Effect sensors, 7-segment LEDs,
and RGB LEDs on the board (145, 38, and 38, respectively) careful planning before routing
signals will be critical. Through hole components (headers and 7-segment displays) add to the
routing complexity. Also, due to the fact that two different power rails (5V and 3.3V) are needed
for components on the PCB, routing signals through and around the PCB will be very complex.
To avoid routing problems, the layout of the RGB drivers, 7-Segment drivers, and multiplexers
will be planned before any component placement is done. Appendix C shows the placement of
the RGB drivers, 7-Segment drivers, and Hall Effect sensors. Every hexagon has one multiplexer
for its 8 Hall Effect sensors. The drivers and multiplexers were placed so that signals are routed
as short a distance from their destination and the components are placed as evenly throughout the
board as possible. The power and ground rail placement was also decided early in the layout
planning process.
Traces must be sized according to the amount of current they will be required to handle.
The power and ground rails will be the widest rails. The 5V rail will provide approximately 2.4A
at max draw (1.7A to the RGB LEDs and 700mA to the Raspberry Pi) [26] [1] [29]. To handle
this current, a trace with a minimum width of 30 mils will be needed [30]. The 3.3V rail will
provide approximately 1.1A at max draw. Thus, a trace with a minimum width of 15 mils must
be used around the board [30]. However, due the length of the traces, wider traces will be used.
The traces that run the 3.3V rail and 5V rail all the way around the board will be much larger
(150mils to be safe). Vias were added to the board on the power rails running throughout the
board so that if there was an issue with voltage drop across the board we could fly wire the
power. All of the smaller power/ground traces that run the width of the board will be40mils wide
due to their length. Also a 2oz copper pour was used as opposed to the standard 1oz copper pour
to help reduce the voltage drop across the board.
11.1 PCB Layout Design Considerations – Microcontroller
The Atmel AVR32 will draw approximately 19 mA of current at peak draw [11]. Thus, no
special considerations are needed for the size of the power traces running to the microcontroller.
The oscillator circuit and decoupling capacitors will need to be located near the microcontroller.
The microcontroller requires a total of four decoupling capacitors, thus their placement and
routing will need to be planned carefully [11].
The microcontroller will be placed where there is adequate space to position all of the
necessary components (oscillator circuit, decoupling capacitors) and where all of the
multiplexers and LED drivers can route easily. Routing of signals from all 19 hexagons to the
microcontroller will be very difficult, so effective placement of the microcontroller is crucial to a
successful layout. The microcontroller was at the center of the board; however, after routing
-32-
ECE 477 Final Report
Spring 2013
many of the long traces on the board it was decided that moving the micro to the outside of the
board would help with the routing process. This creates a few very long signal traces running
along the outside of the board. However, because they are signal traces at 3.3V it should not be a
problem especially with the 2oz copper pour. Another benefit of moving the micro to the outside
is that there will be more room for the decoupling capacitors and the oscillator circuit. The EMI
of the oscillator circuit can be handled better with the extra space also.
As the PCB layout is finalized, the choice of microcontroller placement will be very
important. The microcontroller reset will be placed in close proximity of the micro to prevent
noise from inadvertently resetting the micro. As you can see, component placement for the
microcontroller is a vital step to a successful layout of our PCB due to the number of
components and signals present.
11.2 PCB Layout Design Considerations - Power Supply
A 5V unregulated signal is input to the power supply; the input comes from an external
switch mode power supply that is connected to the PCB via a barrel jack. The barrel jack is
located on the edge of the board for easy accessibility. The external supply is capable of
providing up to 4A of current; our entire board (including the Raspberry Pi) can theoretically
draw about 3.5A at max draw [31]. Thus, traces at least 100 mils wide will be used in the power
supply circuit [30]. The traces will be made as wide as possible to help reduce EMI produced.
Also, a copper pour will be placed throughout the power supply area to help decrease noise in the
circuit.
Power will be routed through the board with power and ground rails running across the
board. The ground rails will made wide to decrease noise. All of our board components are
digital, so EMI should not be a huge issue. Also, because of this only the power supply circuitry
has to be separated from the rest of the board. A micro USB adapter will route the 5V
unregulated input from the board to the Raspberry Pi [29]. Because 3.3V and 5V are needed
throughout the board, a large power rails will be run around the board where they can then be run
throughout the board to distribute the power across the board.
-33-
ECE 477 Final Report
Spring 2013
12.0 Software Design Considerations
The economy and game board are handled by a Raspberry Pi and a microcontroller,
respectively. The Raspberry Pi is running an apache web server with a series of Python CGI's
that are served to a device with Wi-Fi access as simple web pages. The microcontroller
communicates with the Raspberry Pi using a two-wire interface, and controls the board display
and piece sensing using a state machine.
While the Raspberry Pi has little to deal with as far as external peripherals go, other
than Wi-Fi and I2C, the microcontroller has to communicate with 38 RGB LEDs to display
resource information, 19 seven segment displays to display scarcity information, and 145 hall
effect sensors to read where pieces are on the board. The next section (Section 10.1) will
elaborate on these considerations, among others, while Section 10.2 will talk about the specifics
of the software we are developing.
12.1 Software Design Considerations
As indicated in the introduction, the program is primarily a state machine; however the
microcontroller will be performing some polling in many of the states. A state machine was
chosen as it is the most appropriate for emulating the physical game's turn-based system. The
majority of states will poll the current status of the Hall Effect sensors, however, in order to
check for invalid pieces or updates to valid pieces, such as additional pieces placed or pieces
removed. Appendix A has a high-level flowchart of the game flow.
While no data will be stored on the microcontroller in any sort of semi-permanent
form, such as Flash, we will be storing game status on the microcontroller in SRAM with the
program itself. Most of the game information will be stored in structs and arrays, so there are few
special considerations that need to be made for memory. As a result, there will be no way to
restore the game if there is a power outage.
Within the game itself, the microcontroller needs to be able to keep track of the current
board state as well as the current players' turn, while the Raspberry Pi needs to keep track of the
economy and related information. Specifically, the microcontroller will keep a map, likely in an
array or a struct, of every hexagon's resource and scarcity. Additionally, the microcontroller will
keep a multi-dimensional array of the status of each of the Hall Effect sensor's states. Since each
sensor can only have one or two kinds of pieces placed on it, it is quite simple to store a 2dimensional array of the state of every sensor on the board. Finally, an array of positions owned
by each player will need to be kept as well, to determine what piece is owned by what player. As
mentioned earlier, since none of the information needs to be stored after the micro has shut
down, and there isn't a large amount of data to store, it can all be stored live with the program in
SRAM.
-34-
ECE 477 Final Report
Spring 2013
The Raspberry Pi will be keeping track of the economy and some basic player
information. This basically entails each player's available resources, development cards, and
score. For each player, it will also store their name and a timeout value. Additionally, it needs to
store the deck of development cards. Because it uses an asynchronous, non-persistent connection
with the connected devices, these are stored in JSON files in a “players” directory. Because the
JSON store will be available even after the Raspberry Pi has been rebooted, a combination of a
timeout on the JSON files and cookies on the connected devices will ensure the files are valid
and do not need replaced.
The microcontroller only requires a few integrated peripherals. By default, the
microcontroller clocks at a relatively slow speed of 100 kHz, however in order for reasonable
speeds on I2C and SPI, we need the microcontroller to clock faster. We do this by clocking
against an external oscillator which runs at 12 MHz. We additionally need the DSP, as this
microcontroller's random number generator functions are included in the DSP module. We will
need I2C and SPI to communicate with our Raspberry Pi and 7 segment displays, respectively.
The I2C will be running at 100 kHz with the Raspberry Pi as the master. This is simply because it
is much easier to get the microcontroller to work as a slave than it is to get the Raspberry Pi to do
the same. There appears to be little to no documentation on getting the Raspberry Pi to work as
an I2C slave. The SPI will be running in 8-bit Mode 0, as that is what the 7 segment display
drivers require. The SPI will run at 2 MHz. Finally, we will need the GPIO Module to
communicate with the LED drivers and the Hall Effect Sensor multiplexers, and the Delay
module for wait functions. The LED Drivers communicate using a non-standard protocol that is
vaguely reminiscent of SPI, however it deviates just enough from the protocol that we need to
manually communicate with the drivers using some custom functions that communicate over
pins 10 and 11 of Port B. The Hall Effect sensors are connected to 8 to 1 multiplexers, 1 to a
hexagon, that are oriented in a logical table, with each hexagon being a column. The GPIO
Module will select a row and scan for changes in each column using a mask on Port A, where all
of the multiplexers are attached.
Finally, various debug routines are already developed. We have developed a basic
LED Heartbeat test, which simply blinks an LED, an RGB LED Color Test that cycles through
various colors, a Hall Effect Selection Test that will select a specific column (that is, a hexagon),
and watch each hall effect for a change, a 7-Segment display test that lights each segment, an I2C
EEPROM test, where the microcontroller acts as a simple EEPROM, and an I2C Terminal on the
Raspberry Pi, that allows for communication to the microcontroller through I2C through a highly
simplified telnet-style terminal. Many of these can be included as routines in the final product as
self-test functions. Additionally, during the Raspberry Pi's boot up, the RGB LEDs will be
displaying in some visually interesting fashion that will also serve as a self-test.
-35-
ECE 477 Final Report
Spring 2013
12.2 Software Design Narrative
Appendix B shows a high-level diagram of our code modules. After powering on, we
move directly into the microcontroller initialization phase. This module simply calls Atmel
functions for initializing the system clock [32], the various GPIO Pins [33], the I2C Interface
[34], the SPI Interface [35], the random number generator [36], and the delay function [37].
The next phase is the Initial Board Generation phase. This is the phase that generates
the board setup. It effectively contains 2 modules, resource generation and scarcity generation.
The resource generation module selects a random resource out of the resource pool (that is, the
resources that are currently available but not assigned) and assigns it to a particular hexagon.
This generates a map of the available resources on the playing field. The scarcity generation
module selects a random hexagon on the edge of the playing surface that is not a desert, and sets
each hexagon's scarcity from a list of available scarcities in a circular, spiraling fashion. It is
done this way instead of completely randomly so that common numbers are not placed very
close to one another, so the game does not get any points that are “too strong” or “too weak” on
resources.
At this point, the Raspberry Pi will boot, so here's a brief overview of the software
running on it. It uses an apache web server using a few python CGIs, extensive HTML 5 and
CSS 3, and a small bit of AJAX [38] for constant communication. The main display shows the
current resources available and the number of development cards available, along with the
player's current score. Each button calls an external CGI that performs some action. Among
these are the Player Name CGI, that simply changes the player's name. The Trading CGI asks the
player what resources he wishes to trade and with whom, requests a confirmation or modification
on the given player, and returns the confirmation to the requesting player. The Purchasing CGI
asks the player what he wishes to purchase and then removes the resources from his available
resources after confirmation and piece placement. The End Turn CGI ends the turn after a
confirmation. The Game Status CGI returns the scores of all of the current players and their
awards. Finally, there's the Error CGI which will prevent any other action from happening while
there is an error on the playing surface, such as a misplaced piece. Each CGI shows in a modal
dialog box that then communicates its results using simple query strings back to the index page.
The index page calls yet another CGI, which does not have a modal dialog, that simply returns a
1 if the page needs refreshed (that is, there is new information for the given player), or a 0 if it
does not.
After the Raspberry Pi has booted, we enter the initial piece placement stage. This
stage calls modified versions of the Place Road and Place Settlement modules from the game
loop phase for each player, twice (once in forward order, once in reverse order). The Place
Settlement module waits for the player to place a settlement at any given intersection of three
hexagons and stores its position, while the Place Road module waits for the player to place a
road at any of the three lines radiating from the position of the last placed Settlement, which can
be done by simply passing the location of the settlement to the module and checking around it.
-36-
ECE 477 Final Report
Spring 2013
Additionally, it will run a procedure to check for the longest road, which will be done via a
lookup table, containing all possible adjacent positions.
At last, the system enters the game loop. This loop goes through each player's turn and
repeats the same five checks until the player's turn has ended. These checks are mostly looking at
I2C registers for communication from the Raspberry Pi. The first check is the Dice Roll. If the
dice is rolled, it will roll the dice by selecting 2 random numbers between 1 and 6, and adding
them together. This is slightly different then selecting a single random number between 1 and 12,
as the odds are slightly different of rolling any given number (for example, there are 6 different
ways to make a seven with 2 6-sided dice, but only 1 with a 12-sided die). If the roll was a seven,
it will tell the Raspberry Pi to force the players to discard half of their available resources, should
they have more than 7 available, and will then wait for the thief to be moved to a different
position on the board, and will randomly take one resource from any effected player. If the roll
was not a 7, it will simply assign resources based on whatever the roll was. It will then set a flag
to prevent the dice from being rolled again.
The next check is the Development Card check. If a development card is played, it
will check if the card was a knight card, and if so, it will run the move thief routine. If it was not,
it will run the place road routine twice, with the modification in this stage of the game that the
road must be next to a road, settlement, or city owned by the same player. Other than that, the
place road routine is the same as described earlier. If a different sort of development card has
been played, that is, a monopoly card, then the raspberry pi will handle it with no interaction
from the microcontroller. If it is a monopoly card, then all resources of a certain type will go to a
player, which can be done by reassigning the resources that are stored in a JSON file.
Now the microcontroller will check if a piece has been purchased. If a piece has been
purchased, then the microcontroller will enter the appropriate “place routine”. The place road
routine is the same as described in the Development card check, and the place settlement routine
has the added requirement that the settlement be attached to one of the player's existing roads.
The place city routine will first check for a settlement to be removed, and will then require the
city to be placed in that location.
After that, the microcontroller will enter the Update Board State routine. This routine
checks each position on the board to ensure that there has been no change. If there has been a
change, then it checks if it was a legal change. Legal changes at this point are changes that will
launch the Raspberry Pi into the purchasing CGI, which are limited to placing a road at particular
locations, placing a settlement at particular locations, or removing existing settlements with the
intent to place a city. If any other event occurs, or if a player cancels an event that was initiated
physically, then the board and pi will enter an error state that notifies the player of the error using
the RGB LEDs and the Raspberry Pi's interface and wait until the error is corrected before it will
allow the game to continue.
The final check in a player's turn is simply if the player has ended the game. If they
have, this actually initiates a small module of its own that clears the 'dice rolled' flag and moves
to the next player.
-37-
ECE 477 Final Report
Spring 2013
Finally, after the game is complete, the Raspberry Pi will run a CGI that displays the
final game status and asks if they players wish to play again. If so, it will loop back to the initial
board generation state, and if not, it will begin the shutdown sequence. The shutdown module
will basically have the board running something similar to the startup wait display while the
Raspberry Pi shuts down, and after the Pi has shutdown, notify via I2C that it's ready to be
powered off.
The majority of the Raspberry Pi code is complete, with the exception of I2C
communication and the trading CGI, which has yet to be started. The majority of the
microcontroller code has been made into a flowchart, but has not yet been implemented in code.
There are a few minor subroutines that have not yet been made into a flowchart.
12.3 Software Summary
The software for the Hackers of Catron is making progress. While most of the
Raspberry Pi code is complete, the microcontroller's code hasn't yet moved past the test functions
stage. However, the test functions have us communicating with the hardware successfully, and
most of the microcontroller functions have been developed in various flowcharts, which will
make implementation in code relatively simple.
While we do need several modules, SPI, I2C, ADC, GPIO, and Delay, we don't need
anything terribly difficult to set up or that needs much fine tuning, like PWM. All of the modules
have been tested and are working successfully on the Raspberry Pi and the Microcontroller.
Within the next couple weeks, the various code modules that need implemented on the
microcontroller will be completed, which allow us to enter the final testing phase.
-38-
ECE 477 Final Report
Spring 2013
13.0 Version 2 Changes
In the second iteration of the Hackers of Catron, several changes should be made to
improve the game and the construction process.
In respect to the hardware and schematic, the seven segment drivers will be replaced with
shift registers and resistors. This will eliminate the noisy switching on the 3.3V power line and
allow the seven segment displays to appear brighter. The 3.3V power supply will be doubled in
the amount of current it can source to eliminate resets that occur while programming and
stabilize the 3.3V power line. The MISO/MOSI error and incorrect RGB driver address will also
be fixed.
Concerning the PCB, the incorrect footprints for the RGB LEDs will be fixed. There will
be more space between traces to help prevent manufacturing errors.
The package will be modified to easily view the 7 segments and diffuse the LED light
properly. The surface will be raised enough to fully disperse the LED light. The playing surface
will be divided into individual hexagons so that tiles do not bleed into each other. Each hexagon
will have a square cut for the seven segment display to fit flush with the playing surface.
With respect to the web application, more robust features will be added to ensure that the
game cannot be broken or cheated. A faster booting operating system than Raspbian will be
implemented on the Raspberry Pi such as Arch Linux. Apache will be replaced with Monkey or
Bottle. The microcontroller could be replaced with the Raspberry Pi itself.
-39-
ECE 477 Final Report
Spring 2013
14.0 Summary and Conclusions
Throughout the course of the semester we have developed an electronic version of The
Settlers of Catan called The Hackers of Catron. With the assistance of the course staff, we
decided on how we planned to develop the game with the help of the course staff, and came up
with constraints and components based on our design. As we developed the game throughout the
semester, we also performed other analyses that would be important for real-world development
of the project such as the Patent Liability Analysis and the Ethical and Environmental Impact
Analysis. Additionally, we also made a few design considerations for the project, real-world or
otherwise, such as the PCB Layout Design and the Packaging Design considerations. Once we
completed the project, we came up with some ideas as to how we could change it in a future
iteration to make the game better.
The project itself taught us several important things. For example, we learned a lot about
PCB development and design and we learned quite a bit about power considerations. While we
were at it, we learned how to work with our selected microcontroller, and we learned some
algorithms and functions that we had not used before, like the Longest Road algorithm. There are
some things we would change if we were to do it all over again, or if we had the capability to do
it outside the constraints of the class, such as forgoing the microcontroller entirely and putting all
of the logic on the Raspberry Pi. The project was ultimately successful, with only a few minor
bugs at the end of the semester, and looks fairly nice, too.
-40-
ECE 477 Final Report
Spring 2013
15.0 References
[1] Omron, "LED Control IC W2RF004RM," 8 2012. [Online]. Available:
http://components.omron.com/components/web/pdflib.nsf/0/A59093552C8ED1C186257A5D00
77B1D2/$file/W2RV004RM_0812.pdf. [Accessed 31 1 2013].
[2] AMS, "AS1116 LED Driver IC," [Online]. Available:
http://www.ams.com/eng/Products/Lighting-Management/LED-Driver-ICs/AS1116. [Accessed
31 1 2013].
[3] Catan, "The Settlers of Catan," [Online]. Available: http://www.catanshop.com/The-Settlersof-Catan-P19C2.aspx. [Accessed 31 1 2013].
[4] Apple, "Catan HD," [Online]. Available: https://itunes.apple.com/us/app/catanhd/id390422167?mt=8. [Accessed 31 1 2013].
[5] Catan GmbH, "Information about PlayCatan," [Online]. Available:
http://www.playcatan.com/info-contact.html. [Accessed 31 1 2013].
[6] Hasbro, "MONOPOLY Brand Electronic Banking Edition," [Online]. Available:
http://www.hasbro.com/monopoly/en_US/shop/details.cfm?R=9367A23C-6D40-1014-8BF09EFBF894F9D4:en_US. [Accessed 31 1 2013].
[7] M. Haltovsky et al., “Multi-player, multi-screens, electronic gaming platform and system,”
U.S. Patent 8 226 476 B2, Jul. 24, 2012.
[8]
P. Gilboa, “Computerized game board,” U.S. Patent 5 853 327, Dec. 29, 1998.
[9] R.G. Baker, “Digitizing apparatus having array of hall effect sensors,” U.S. Patent 5 734
130, Mar. 31, 1998
[10]
“Military Handbook,”1 1990. [Online]. Available:
http://snebulos.mit.edu/projects/reference/MIL-STD/MIL-HDBK-217F-Notice2.pdf [Accessed
2 4 2013].
[11]
Atmel, “32-bit ATMEL AVR Microcontroller,” 1 2012. [Online]. Available:
http://www.atmel.com/Images/32059s.pdf [Accessed 4 2 2013].
[12]
Texas Instruments, “LM2675 SIMPLE SWITCHER,” 4 2004. [Online]. Available:
http://www.ti.com/lit/ds/symlink/lm2675.pdf [Accessed 4 4 2013].
-41-
ECE 477 Final Report
Spring 2013
[13] Wikipedia, “Printed circuit board,” 5 4 2013. [Online]. Available:
http://en.wikipedia.org/wiki/Printed_circuit_board. [Accessed 10 4 2013].
[14] Environmental Resource Site for SME Manufacturers, “Overview of Printed Circuit
Board Industry,” 2007. [Online]. Available:
http://www.sme.greenmfr.org/english/printed/printed.html. [Accessed 10 4 2013].
[15] Wikipedia, “Poly(methyl methacrylate),” 9 4 2013. [Online]. Available:
http://en.wikipedia.org/wiki/Acrylic_glass. [Accessed 10 4 2013].
[16] Acrylite, “Acrylite LED color-changing back lit (black/white P95),”
[Online]. Available: http://www.acrylite-shop.com/pdfs/3667a%20P95%20Black%20and%20White%20sell%20sheet.pdf. [Accessed 10 4 2013].
[17] Wikipedia, “Integrated Circuit,” 6 4 2013. [Online]. Available:
https://en.wikipedia.org/wiki/Integrated_circuit. [Accessed 10 4 2013].
[18] Wikipedia, “Acrylonitrile butadiene styrene,” 12 3 2013. [Online]. Available:
http://en.wikipedia.org/wiki/Acrylonitrile_butadiene_styrene. [Accessed 10 4 2013].
[19] Wikipedia, “Polylactic acid,” 3 1 2013. [Online]. Available:
http://en.wikipedia.org/wiki/Polylactic_acid. [Accessed 10 4 2013].
[20] 1800Recycling.com, “1800Recycling.com,” 2013. [Online]. Available:
http://1800recycling.com/. [Accessed 10 4 2013].
[21] Magnetic Component Engineering, “Disposal of Magnets…,” 2009. [Online]. Available:
http://www.mceproducts.com/knowledge-base/article/article-dtl.asp?id=11. [Accessed 10 4
2013].
[22] Lifehacker, “How to Crack a Wi-Fi Network’s WPA Password with Reaver,” 9 1 2012.
[Online]. Available: http://lifehacker.com/5873407/how-to-crack-a-wi+fi-networks-wpapassword-with-reaver. [Accessed 10 4 2013].
[23]
Board Game Geek, “Dungeons and Dragons Computer Labyrinth Game,” [Online].
Available: http://boardgamegeek.com/boardgame/4746/dungeons-dragons-computerlabyrinth-game [Accessed 2 2 2013].
-42-
ECE 477 Final Report
Spring 2013
[24]
Board Game Geek, “The Generals Electronic Strategy Game,” [Online]. Available:
http://boardgamegeek.com/image/756547/the-generals [Accessed 2 2 2013].
[25]
Kingbright, “Dual Digit Numeric Display,” 3 2011. [Online]. Available:
http://www.mouser.com/ds/2/216/DC56-11EWA-43385.pdf [Accessed 4 2 2013].
[26]
Cree, “Cree® PLCC4 3 in 1 SMD LED,” [Online]. Available:
http://www.mouser.com/ds/2/90/CLV1L%20FKB%201238-218261.pdf
[27]
Evonik Industries, “Acrylite Satin Ice,” [Online]. Available: http://www.acryliteshop.com/US/us/acrylite-sheet/satinice-satin-ice-df-8ww9w0k5tzz.html
[28]
Toshiba, “TCS20DLR,” 2 2011. [Online]. Available:
http://www.semicon.toshiba.co.jp/info/docget.jsp?type=datasheet&lang=en&pid=TCS20DLR
. [Accessed 13 2 2013]
[29] Broadcom Corporation, “BCM2835 ARM Peripherals,” 2 2012. [Online]. Available:
http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARMPeripherals.pdf. [Accessed 21 2 2013].
[30] Purdue ECE 477 Staff, “PCB Design Specifications,” 18 7 2011. [Online]. Available:
https://engineering.purdue.edu/ece477/Homework/CommonRefs/Tutorials/PCB/PCB%2
0Design%20Specifications.pdf. [Accessed 21 2 2013].
[31] Triad Magnetics, “External Switchmode Power Supplies - WSU Series,” 3 2012.
[Online]. Available: http://triadmagnetics.com/pdf/WSUSeries%20datasheet%20(2012).pdf. [Accessed 21 2 2013].
[32]
Atmel, “System Clock Management,” 26 2 2013. [Online]. Available:
http://asf.atmel.com/docs/latest/common.services.basic.clock.example1.evk1101/html/group__sy
sclk__group.html#ga242399e48a97739c88b4d0c00f6101de. [Accessed 21 3 2013].
[33]
Atmel, “GPIO - General-Purpose Input/Output,” 26 2 2013. [Online]. Available:
http://asf.atmel.com/docs/latest/uc3b/html/group__group__avr32__drivers__gpio.html.
[Accessed 21 3 2013].
[34]
Atmel, “Quickstart guide for Common service TWI,” 26 2 2013. [Online]. Available:
http://asf.atmel.com/docs/latest/uc3b/html/twi_quickstart.html. [Accessed 21 3 2013].
-43-
ECE 477 Final Report
Spring 2013
[35]
Atmel, “SPI - Serial Peripheral Interface,” 26 2 2013. [Online]. Available:
http://asf.atmel.com/docs/latest/uc3b/html/group__group__avr32__drivers__spi.html. [Accessed
21 3 2013].
[36]
Atmel, “op_fix_rand.c,” [Online]. Available:
http://asf.atmel.com/docs/latest/avr32.services.dsplib.example.dsp32_iirpart.evk1100/html/op__i
x__rand_8c_source.html. [Accessed 21 3 2013].
[37]
Atmel, “Busy-Wait Delay Routines,” 26 2 2013. [Online]. Available:
http://asf.atmel.com/docs/latest/uc3b/html/group__group__common__services__delay.html.
[Accessed 21 3 2013].
[38]
AjaxPatterns, “Periodic Refresh,” 20 2 2013. [Online]. Available:
http://ajaxpatterns.org/Periodic_Refresh. [Accessed 21 3 2013].
-44-
ECE 477 Final Report
Appendix A:
A.1
Spring 2013
Individual Contributions
Contributions of Josh Hunsberger:
Before the semester began, I proposed the idea of doing an electronic version of Settlers of Catan
as a project. There were several major design challenges brought up by this idea, especially how
to sense all the pieces on the board. When we decided that Settlers would in fact be our final
project idea, I began looking into initial piece detection methods. First I looked into different
piece sensing methods, including RFID, plug-in contacts, physical switches, Hall Effect sensors,
reed switches, capacitive sensors, and video image processing. After eliminating each method
one by one, I settled on hall effect sensors or reed switches as being the only legitimate methods.
I also looked into how to get all that data back to a microcontroller. I decided a keyboard
controller would be too slow and a keypad layout would take too many pins. Therefore we went
with multiplexing all the inputs. After our initial project proposal was questioned because it
called for 19 individual PCBs, I worked hard to help select new parts which would work together
on a single, large PCB.
As the member of the team most focused on hardware, I did a lot of the early prototyping and
passive calculations. I made sure we got the right sizes for our Hall Effect pull up resistors and
our RGB LED current limiting resistors. I helped pre-order some parts and tested them to make
sure they functioned as we believed they would. I soldered together a pair of Hall Effect sensors
to see if it was feasible to detect magnets without false positives. I also put a lot of time into
calculating power consumption of our board to make sure we could supply enough current. Also
I took primary responsibility for testing different types of magnets to find the best fit for our
needs.
After initial prototyping stage was mostly complete, I worked on building the schematic for the
PCB. Due to the nature of our project, there was a lot of repetition within the different circuit
modules, which resulted in a lot of copying and pasting. Later, this would lead to an improperly
wired RGB driver and swapping of the MCU’s MISO and MOSI lines. Fortunately both were
fixable. The final schematic consisted of 23 pages.
After finishing the schematic I focused my efforts on programming the microcontroller. I worked
closely with Ryan on low-level code. We were able to implement SPI, I2C, and PLL functions
on the MCU before the PCB was finished. When the PCB arrived, I worked at soldering and
testing the various modules, especially the power supply. When the 7-Segment drivers started to
make our power supply crash, I spent most of my time trying to clean up the noise on the Vdd
line. Around this time I also looked into possible patent infringements.
1
ECE 477 Final Report
Spring 2013
Once the bugs in the physical circuit were all worked out, I again focused on programming. I
helped make a flowchart of the high-level pseudo-code since I was the one most familiar with the
game. I wrote most of the code that generates random sequences of resource tiles so that the
board can be a new, random game each time. I also wrote functions to roll a pair of dice, assign
resources to players based on dice rolls, check if pieces placed on the board were legal, and find
the longest road.
While not working on microcontroller functions, I worked with Spencer on interfacing the
Raspberry Pi and the microcontroller. The last couple of weeks I mostly spent making small
changes in our microcontroller functions to make them better work with the Raspberry Pi and
fixing some small bugs.
2
ECE 477 Final Report
A.2
Spring 2013
Contributions of Spencer Julian:
Throughout the project, my focus was less on the hardware and more on the software side of
things. Even so, I did assist some with the hardware, packaging, and the general design of the
Hackers of Caton. My experience was mostly useful on the Raspberry Pi, however, as I have had
a significant amount of Linux experience outside of class and am also relatively familiar with
Python as a scripting language, though I had not used Python as a web programming language
until this project. Also, my skills in visual design were called upon a little bit for coming up with
the base design of the web interface, which Robert enhanced quite a bit, and for coming up with
the general visual theme of the project, along with developing some parts of the packaging.
Finally, my skills as a hobbyist were called upon occasionally for some intuitive sense on what
would and would not work for the project.
Toward the beginning of the semester, I was quite active in deciding what components we should
use. While I did assist a bit in deciding things such as the LEDs and the drivers and the like, I
was mostly involved in selecting the microcontroller and motherboard that we would be using.
As a part of this process, I tested the BeagleBoard and the Raspberry Pi and compared the two,
and ultimately decided on the Raspberry Pi. I also tested various distributions of linux to run on
the Raspberry Pi with Robert’s help, but we ultimately decided on Raspbian, despite its slow
start, for its ease of use and significant amount of documentation available online.
Once we had selected our components, I assisted a bit with packaging design, though not a
significant amount at this point. Most of my time at this point was spent setting up the Raspberry
Pi for use, such as setting up an Access Point, again with Robert’s help, selecting the web server
and other various bits of software to use, and trimming down the boot services so it’s only
running explicitly what we need.
While working on the Raspberry Pi’s operating system, I was working a bit on finding
reasonable methods of communication of the microcontroller with the various drivers we had
selected, based on Robert’s experience with the mbed and what I could find online. I discovered
the I2C communication and some of the other communication glue online and through the asf
user guide, which Josh and Ryan eventually converted into the final functions that are used in the
source code.
I began working a bit on the web interface, as there was a good portion of it that would need to
be developed before we could even interface it with the microcontroller. As such, I was working,
mostly independently at this point, on the web interface to ensure we had something that we
could get to talk with the microcontroller over I2C. I selected all of the python libraries that we
used and the like on the Raspberry Pi itself.
3
ECE 477 Final Report
Spring 2013
Once the basic web interface was done, I began interfacing it with the microcontroller and
building the base web interface. It was slow, but it worked. This involved communicating with
the microcontroller via I2C and deciding how to facilitate communication - Josh and I decided on
using the microcontroller as an EEPROM as it was easier to get the microcontroller to operate in
slave mode than it was to get the raspberry pi to operate in slave mode.
After we got the basic communication accomplished, and finished the main web interface, we all
decided that the web interface was immensely slow and Robert and I worked on redeveloping it
to be faster. I changed our web server from using a CGI to a WSGI, and I converted our code
from Python 2.7 to Python 3 to work with the quick2wire libraries. In the process, we also added
an additional python library known as bottle, which is a third-party library that acts as an
intermediary between the actual code and the WSGI functions Python 3 provides, and simplifies
it greatly. After Robert developed a basic skeleton, I ported our original code to bottle and
updated the backend as necessary, while Robert worked mostly on updating the frontend and
utilizing more javascript to help speed up load times. The result was much faster and easier to
use. At this point it boiled down to feature addition and bug squashing, and eventually was ready
to display. Of course, I assisted in the senior design showcase, as well.
4
ECE 477 Final Report
A.3
Spring 2013
Contributions of Robert Harris:
During the fall semester we met several times as a team to discuss our plan for this semester’s
project. In the first week of this semester we met and completed the preliminary proposal. The
next week we worked on the Final Project Proposal. I contributed to the block diagram and parts
spreadsheet. I contacted Advanced Circuits about purchasing a large PCB to confirm that we
could get a 50% student discount.
During week 3 I completed the Eagle PCB tutorial. I began testing a driver and RGB LED using
an Mbed ARM development board. My Raspberry Pi and SD card came in so I began working it
with Debian Linux. I attempted to get an access point running with hostapd but had issues.
During week 4 I worked on setting up a test circuit for the 7 segment driver with Ryan. I worked
on the Design Constraint Analysis homework. For the homework I did research on the different
components that we had begun prototyping and looked into other alternatives. I presented the
TCSP on Wednesday and submitted the homework on Friday. I got a software access point
running on my Raspberry Pi. Also, I obtained an AVR Dragon from Aditya and was able to
recognize our microcontroller using AVR Studio on my laptop.
During week 5 I was able to program the micro with the Dragon Board and illuminate an LED. I
looked into the libraries and documentation available through ATMEL. I tried to get SPI
working with the LED driver using the Mbed board but had no luck.
During week 6 I worked on the RGB LED drivers with Ryan. I looked into ways to better diffuse
the light from the RGB LEDs. I continued testing the 7-segment display driver with the Mbed.
Helped Josh with the block diagram for the schematic homework. I began looking into the PCB
layout homework.
During weeks 7, 8, and 9 I worked on the PCB Layout. I did all of the work in Eagle on the
layout of our PCB. I worked with Ryan to come up with a way to place the hall effect
multiplexers and hall effect sensors in a way that resulted in each hexagon (except for the middle
one) having one multiplexor. I came up with ways to place the RGB and 7-segment drivers on
the board. I started by creating a silkscreen to help line up all of the sensors, multiplexers, 7segments, 7-segment drivers, RGB LEDs, and RGB LEDs drivers. All pieces were placed on the
board. Due to the massive size of the PCB (20.5”x16.0”) I first used auto route to get an idea of
how well it would work. Auto route did not work well with the power and ground traces
especially. I presented on at the PCB Layout TCSP. I also completed and submitted the PCB
homework. After the TCSP I decided to route the power traces by hand and then use auto route
for everything else. The results still were not good enough. I started by routing one hexagon by
hand to see if it was possible. So I decided to route the entire board by hand. This took lots of
work and went through several revisions. Initially the 3.3V and 5.5V rails ran on opposite sides
5
ECE 477 Final Report
Spring 2013
of the board and the ground rail was on the same side as the 3.3V rail. Added standoffs modified
the power supply and added decoupling capacitors for the 7-segment drivers. Added a ground
plane to the entire board but it was not effective because of the 3.3V and 5V power rails. So the
3.3V and 5V rails were moved to the same side of the board. This allowed the ground plane to
have more parallel connections back to the power supply’s ground connection. I changed the
routing of some of the long signals around the board to shorten them. I contacted Advanced
Circuits to ask about a 2oz copper fill. I made last minute changes to the PCB and went through
and checked for acid traps and other problems. Changed the silkscreen to show what we needed
concisely. As a team we added the team name, logo, and our names to the silkscreen. The PCB
order was placed. I looked into what standoffs we needed and ordered them over spring break.
After Spring break we discussed software design and created an initial state transition diagram.
The PCB came in and we began soldering. Because of problem with RGB LED footprint we all
had to scrape off some of the solder mask which was time consuming. We worked as a team to
discuss the project timeline, packaging details, and a few software issues. I soldered several RGB
LED drivers and RGB LEDs. I soldered a lot of the Hall Effect sensors and multiplexers on the
board. Found a problem with two of the mux return lines that were shorted. I could not find the
problem after lots of debugging; Joe suggested charging a large capacitor up to 25V and
applying it to the traces (with no components connected) to remove any hairline shorts. It
worked; it must have been a manufacturing error. Ryan and I found out (by using the logic
analyzer) that the MISO and MOSI pins for the 7-segment drivers were swapped. I cut two traces
on the bottom of the board and fly wired them correctly. I soldered several 7-segments and 7segment drivers. Ryan discovered an RGB driver with an incorrect address so I fly wired one of
the address pins on a driver to ground.
As a team we looked into the power issues related to the 7 segment displays. We added more
capacitance and ended up running them at 50% brightness. I aided in the construction of the
packaging of the project.
Finally, I helped port the Python web server code to the bottle framework and I wrote some of
the CSS/HTML for the web app. I helped with the testing and debugging of the game.
6
ECE 477 Final Report
A.4
Spring 2013
Contributions of Ryan Pawling:
My areas of specialty in this project were primarily the microcontroller software and prototyping.
As a result, most of my contributions consist of interfacing the microcontroller with our various
drivers and components, as well as designing the game logic on the board.
Prior to beginning this project, I had never played The Settlers of Catan, and had a lot to learn
about the rules of the game and how the game play mechanics could be realized in hardware. In
the initial team meetings, I contributed by penning the preliminary proposal as we discussed
necessary parts and costs. I worked with Josh to create the first block diagram which consisted
of 19 AT Tiny microcontrollers on 19 different PCBs. Fortunately, after Rob and I spoke with
Blaine about our design, this plan was scrapped in favor for a large PCB using multiplexors and
drivers.
I wrote the final proposal as well as aided in the search for components for our design. I located
a suitable seven segment driver and seven segment displays, since we did not want to crowd our
PCB with shift registers and resistors.
Once we had our sample parts, I began prototyping with an mbed development board. I was able
to interface with it once I realized it used a custom protocol, not I2C. I wrote a simple test code
to toggle the red, green, and blue LEDs.
With input from the team concerning our packaging constraints, I began work on the initial
packaging design. Using AutoCAD Inventor, I designed a CAD drawing with our intended
dimensions. These measurements would end up changing slightly since the surface of our
package was dependent on the size of the PCB. Met with the team for feedback and iterated on
the packaging design. During this time I also designed the footprints for several major
components in eagle and populated a sample PCB to find a rough estimate of the size at 18x16
inches.
With the help of Josh, we were able to fully prototype all our micro interfaces. This includes SPI
for the seven segment drivers, I2C for the raspberry pi, TWI for the RGB drivers, and
multiplexor addressing for the Hall Effect sensors. Josh and I had test code for all the interfaces
ready before the PCB arrived so that we could verify our solder connections as we populated the
board.
Once the PCB arrived, everyone on the team contributed to the population of the board. I
worked with Rob to debug a MISO/MOSI switch up issue on the seven segment driver which
involved cutting the traces and a short fly wire. During this time, I worked with Josh to flesh out
several flowcharts for the game logic and microcontroller software.
7
ECE 477 Final Report
Spring 2013
Once the PCB was complete and debugged, I spent much time working on organizing the code
and designing low level functions with Josh. Once we reached the game logic, I wrote functions
to generate random rarities, check for legal piece placement, the main game loop, the relational
map of all positions on the board and its API, and several RGB LED animations. With Josh, I
worked on the check board state and longest road functions, as well as debugging play.
In the interim I worked with Spencer and Rob, scoring and breaking pieces of acrylic to be glued
together to form the packaging for the board. Additionally, I completed the reliability and safety
analysis of the design.
When the microcontroller code was complete, I spent some time with Spencer to debug
communication between the microcontroller and raspberry pi, and fix any microcontroller bugs
that we found. I also worked with Rob to make a video displaying our project and PSSCs.
8
ECE 477 Final Report
Appendix B:
Spring 2013
Packaging
Figure B-1: Rendered Drawing
Figure B-2: Hex Divider Rendered Drawing
1
ECE 477 Final Report
Spring 2013
Figure B-3: Top View Measured Drawing
2
ECE 477 Final Report
Appendix C:
Spring 2013
Schematic
Figure C-1: Microcontroller
1
ECE 477 Final Report
Spring 2013
Figure C-2: Hall Effect Network 0
2
ECE 477 Final Report
Spring 2013
Figure C-3: Hall Effect Network 1
3
ECE 477 Final Report
Spring 2013
Figure C-4: Hall Effect Network 2
4
ECE 477 Final Report
Spring 2013
Figure C-5: Hall Effect Network 3
5
ECE 477 Final Report
Spring 2013
Figure C-6: Hall Effect Network 4
6
ECE 477 Final Report
Spring 2013
Figure C-7: Hall Effect Network 5
7
ECE 477 Final Report
Spring 2013
Figure C-8: Hall Effect Network 6
8
ECE 477 Final Report
Spring 2013
Figure C-9: Hall Effect Network 7
9
ECE 477 Final Report
Spring 2013
Figure C-10: Hall Effect Network 8
10
ECE 477 Final Report
Spring 2013
Figure C-11: RGB LED Driver 0
11
ECE 477 Final Report
Spring 2013
Figure C-12: RGB LED Driver 1
12
ECE 477 Final Report
Spring 2013
Figure C-13: RGB LED Driver 2
13
ECE 477 Final Report
Spring 2013
Figure C-14: RGB LED Driver 3
14
ECE 477 Final Report
Spring 2013
Figure C-15: RGB LED Driver 3
15
ECE 477 Final Report
Spring 2013
Figure C-16: RGB LED Driver 4
16
ECE 477 Final Report
Spring 2013
Figure C-17: RGB LED Driver 5
17
ECE 477 Final Report
Spring 2013
Figure C-18: 7-Segment Driver 0
18
ECE 477 Final Report
Spring 2013
Figure C-19: 7-Segment Driver 1
19
ECE 477 Final Report
Spring 2013
Figure C-20: 7-Segment Driver 2
20
ECE 477 Final Report
Spring 2013
Figure C-21: 7-Segment Driver 3
21
ECE 477 Final Report
Spring 2013
Figure C-22: 7-Segment Driver 4
22
ECE 477 Final Report
Spring 2013
Figure C-23: Power Supply
23
ECE 477 Final Report
Appendix D:
Spring 2013
PCB Layout Top and Bottom Copper
A copy of the top and bottom copper PCB layout (with silkscreen) should be included here – note
that all figures should be numbered and captioned.
Figure D-1: PCB Top and Bottom View
1
ECE 477 Final Report
Spring 2013
Figure D-2: PCB Top Copper View
2
ECE 477 Final Report
Spring 2013
Figure D-3: PCB Bottom Copper View
3
ECE 477 Final Report
Appendix E:
Vendor
Spring 2013
Parts List Spreadsheet
Manufacturer
Part No.
Digi-Key
Toshiba
TCS20DLR
Digi-Key
Digi-Key
AMS
Atmel
AS1116
AT32UC3B064
Allied
Electronics
Raspberry Pi
Found.
Raspberry Pi
Model B
Mouser
Omron
W2RF004RM
Mouser
Kingbright
Mouser
Description
Digital Output
Magnetic
Sensor (H.E.)
64 LED Driver
32-bit AVR
Microcontroller
Unit 7.0 Qty
Cost
0.312
145
Total
Cost
$14.90
6.57
7.48
5
1
$32.85
$7.48
Motherboard
Device - Mini
ARM PC
LED Control IC
35.00
1
$35.00
2.94
7
$20.58
DC56-11EWA
Red 2-Digit 7Segment
Comm. Cathode
2.08
20
$41.60
Texas
Instruments
SN74HC151PW
8-Line to 1-Line
Multiplexer
0.46
18
$8.28
Mouser
Cree
CLV1L-FKB
0.24
38
$9.12
4pc
4pcb
N/A
485.00
1
$475.00
Amazon
Tenda
W311MI
3 in 1 SMD
LED
18”x22” 2-layer
PCB
Wi-Fi Adapter
10.00
1
$10.00
TOTAL
$695.15
1
ECE 477 Final Report
Appendix F:
Spring 2013
FMECA Worksheet
Subsystem A: Power Supply
Failure
No.
Failure Mode
A1
Low 3.3
Voltage on
board
A2
Possible Causes
Failure Effects
Method of
Detection
Voltage regulator
failure, potentiometer
failure, shorted bypass
capacitor
Board does not power up,
board is not responsive
even after webserver
powers up, 7 segments are
dim, RGB LEDs do not
animate
Observation
Medium
May damage
other components
High 3.3
Voltage on
board
Voltage regulator
failure, potentiometer or
resistor open circuit
Board does not power up,
board freezes and becomes
unresponsive, 7 segments
flicker
Observation
High
May damage
other
components, may
overheat voltage
regulator
A3
Unstable 3.3
Voltage on the
board
Too much current draw
from 7 segment displays,
7 segment driver or buck
switcher is too noisy,
bulk capacitor failure
Seven segment displays
flicker, board freezes and
becomes unresponsive
Observation
Medium
May damage
other components
A4
Unstable 5.0
Voltage on the
board
Wall wart failure,
voltage regulator failure
Raspberry pi does not start, Observation
board does not power up,
RGB LEDs flicker
Medium
May damage the
Raspberry Pi
1
Criticality
Remarks
ECE 477 Final Report
Spring 2013
Subsystem B: Hall Effect Sensor Network
Failure
No.
Failure Mode
Possible Causes
Failure Effects
Method of
Detection
Criticality
Remarks
B1
Hall effect
sensor always
outputs 0
Hall effect sensor shorted
to ground, resistor
network is open,
multiplexer failure,
microcontroller gpio pins
used for hall effects
failure
Piece will be detected
where there is not
one; game will likely
get trapped in an
error state
Test Sequence,
Observation
Low
Test sequence
explained in
section 3.3
B2
Hall effect
sensor always
outputs 1
Hall effect sensor shorted
to power, resistor network
is shorted, multiplexer
failure, microcontroller
gpio pins used for hall
effects failure
Position will become
unusable and cannot
place a new piece
Test Sequence,
Observation
Low
B3
Unstable Hall
Effect Output
Hall effect sensor
damaged, bypass
capacitor is shorted,
multiplexer failure
Position will
sometimes detect a
piece and sometimes
not
Test Sequence,
Observation
Low
B4
Hall effect
sensor also
triggers
adjacent sensor
Pullup resistor network or
multiplexer connections
are shorted
Adjacent positions
Test Sequence,
detect the same piece Observation
Low
2
maybe the resistor
network is heating
up and shorting
the solder
connections
ECE 477 Final Report
Spring 2013
Subsystem C: RGB LED Display
Failure
No.
Failure Mode
Possible Causes
Failure Effects
Method of
Detection
Criticality
C1
RGB driver
channel is not
modulating
Internal RGB PWM failure,
input/out pins on
driver/micro are faulty,
software
LED on the affected
channel will not be
driven
Observation
Low
C2
RGB driver
registers reset
unexpectedly
Short in the decoupling cap
on the reset switch, timing
error in RGB data transmit
from micro, unstable 3.3
voltage
LEDs using the
affected driver will
all switch off
Observation
Low
Remarks
Subsystem D: Rarity Display
Failure
No.
Failure Mode
Possible Causes
Failure Effects
Method of
Detection
Criticality
D1
7 Segment driver
is stuck on one
digit
Internal scanning
mux is damaged,
software
Only 5 digits of
the rarity will be
displayed;
brighter than
normal
Observation
Low
3
Remarks
ECE 477 Final Report
Spring 2013
D2
7 Segment driver
registers do not
latch new data
SPI bus too noisy,
driver failure,
microcontroller load
signal failure/timing
error
Rarity cannot be
displayed on the
board or changed
Observation
Low
D3
7 Segment
Display does not
light
Current limiting
resistor on the driver
is shorted, driver’s
digit select lines are
stuck at high
impedence
Rarity cannot be
displayed on the
board
Observation
Low
Short in the current
limiting resistor could
have burned out all
segments, causing it not
to light
D4
7 Segment
Display has
burned out
segments
Current limiting
resistor has been
shorted, driver is
sinking too much
current
Rarity display
will have missing
segments
Test Sequence,
Observation
Low
There will be a test
sequence to check for
burn outs; the driver has
diagnostic options
Subsystem E: Microcontroller
Failure
No.
Failure Mode
Possible Causes
Failure Effects
Method of
Detection
Criticality
E1
Reset is triggered
on the micro
Pull-up resistor for
reset switch is open,
decoupling capacitor
is open, reset switch
is stuck closed
Game board will
restart
Observation
Low
4
Remarks
ECE 477 Final Report
E2
The micro stops
executing
instuctions
Spring 2013
External oscillator
failure, noise on 3.3V
power, software
5
Game board is
frozen
Observation
Low