EE 477 Final Report · Web viewA 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

ECE 477 Final ReportSpring 2013Team #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 SCORE MPY PTSTechnical content 0 1 2 3 4 5 6 7 8 9 10 3Design documentation 0 1 2 3 4 5 6 7 8 9 10 3Technical writing style 0 1 2 3 4 5 6 7 8 9 10 2Contributions 0 1 2 3 4 5 6 7 8 9 10 1Editing 0 1 2 3 4 5 6 7 8 9 10 1Comments: TOTAL

ECE 477 Final Report Spring 2013

1.0 Table of Contents

Abstract............................................................................................................................................13.0 Project Overview and Block Diagram..................................................................................14.0 Team Success Criteria and Fulfillment.................................................................................35.0 Constraint Analysis and Component Selection....................................................................56.0 Patent Liability Analysis.....................................................................................................107.0 Reliability and Safety Analysis..........................................................................................148.0 Ethical and Environmental Impact Analysis......................................................................209.0 Packaging Design Considerations......................................................................................2410.0 Schematic Design Considerations......................................................................................2811.0 PCB Layout Design Considerations...................................................................................3212.0 Software Design Considerations.........................................................................................3413.0 Version 2 Changes..............................................................................................................3914.0 Summary and Conclusions.................................................................................................4015.0 References...........................................................................................................................41Appendix A: Individual Contributions.....................................................................................A-1

A.1 Contributions of Josh Hunsberger:...............................................................................A-1A.2 Contributions of Spencer Julian:...................................................................................A-3A.3 Contributions of Robert Harris:....................................................................................A-5A.4 Contributions of Ryan Pawling:...................................................................................A-7

Appendix B: Packaging............................................................................................................B-1Appendix C: Schematic............................................................................................................C-1Appendix D: PCB Layout Top and Bottom Copper.................................................................D-1Appendix E: Parts List Spreadsheet..........................................................................................E-1Appendix F: FMECA Worksheet..............................................................................................F-1

-ii-


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-


Figure 1-2 Finished Design

-2-


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.2PSSC 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.3PSSC 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-


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-


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-


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-


Table 3-1 - Interface/On-Chip Peripheral Requirements SummaryMicrocontroller Motherboard

Quantity Description Quantity Description22 General Purpose I/O 1 UART/I2C2 UART/I2C 1 USB1 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 SummaryQuantity Description Interface Interfaced With

5 7-Segment Driver SPI Microcontroller7 LED Driver TWI Microcontroller18 8:1 Multiplexer GPIO Microcontroller1 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-


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 ComparisonCost (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 RationaleSee 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 ComparisonAtmel AT32UC3B064 Microchip PIC24FJ64GB004

Architecture 32-bit 16-bitOperating Voltage 3-3.6 V 2-3.6 VI/O Pins 44 I/O Pins

3 USART (also SPI) 1 I2C 1 SPI

35 I/O Pins 2 UART 2 I2C 2 SPI

Clock Speed 60 MHz 32 MHzFlash Memory 64 KB 64 KB SRAM 16 KB 16 KB Pricing $7.48, Free Sample Available $3.74, Free Sample Available

-8-


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 ComparisonRaspberry Pi Model B Beagle Board

SOC Broadcom BCM2835 OMAP3530CPU ARM1176JZFS ARM Cortex-A8I/O UART/I2C

SPIUSB 2.0

UART/I2CSPIUSB 2.0

Clock Speed 700 MHz 600 MHzFlash Memory SD Card 256 MB + SD CardSRAM 512 MB 128 MBPricing $35.00 $149.00

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-


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 non-discretely 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-


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-


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-


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-


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-


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-


π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]


C1 Die complexity 0.02 101 - 300 linear gates

πT Temperature coeff. 16 operating at < 100C


0.0072 16-pin SMD





MTTF 1 Buck on board 34.1 years

Omron W2RV004RM RGB LED Driver [1]


C1 Die complexity 0.08 3001-10000 digital gates



0.013 28-pin SMD




-16-



MTTF with 6 Drivers on board

109.3 years

AS1116 7 Segment Driver [2]


C1 Die complexity 0.08 3001-10000 digital gates



0.011 28-pin SMD





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-


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-


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-


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-


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-


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-


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-


15.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.

15.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.

15.1.1Commercial 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-


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.

15.1.2Commercial 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-


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.

15.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-


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.

15.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).

15.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-


16.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.

16.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 daisy-chained 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-


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 SummarySubsection Component Function Operation

Sensor Hall Effect sensor Detect piece 3.3V, active low, open

drain, .47uF bypass cap,

15kΩ Pull up resistor

Multiplexer Organize sensors, reduce pin

count

3.3V, complemented output,

3 SEL lines, 8:1

RGB RGB LED 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

-29-


8digit driver Control 7seg display 3.3V, 160mA/digit, SPI

Input: 1 data line, 1 load-

enable, 1 clock

Output: 1 data line

16.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 AssignmentPorts Subsystem Function

PA09, 10 TWI Raspberry Pi communication

PA14...16, 28 SPI Control 7seg display

-30-


PA20...22 GPIO Select address lines for sensor array

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

16.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-


17.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.

17.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-


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.

17.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-


18.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.

18.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 2-dimensional 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-


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-


18.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-


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-


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.

18.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-


19.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-


20.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-


21.0 References

[1] Omron, "LED Control IC W2RF004RM," 8 2012. [Online]. Available: http://components.omron.com/components/web/pdflib.nsf/0/A59093552C8ED1C186257A5D0077B1D2/$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-Settlers-of-Catan-P19C2.aspx. [Accessed 31 1 2013].

[4] Apple, "Catan HD," [Online]. Available: https://itunes.apple.com/us/app/catan-hd/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-8BF0-9EFBF894F9D4: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-

http://www.ti.com/lit/ds/symlink/lm2675.pdf

http://www.ti.com/lit/ds/symlink/lm2675.pdf

http://www.atmel.com/Images/32059s.pdf

http://www.atmel.com/Images/32059s.pdf

http://snebulos.mit.edu/projects/reference/MIL-STD/MIL-HDBK-217F-Notice2.pdf

http://snebulos.mit.edu/projects/reference/MIL-STD/MIL-HDBK-217F-Notice2.pdf

http://www.hasbro.com/monopoly/en_US/shop/details.cfm?R=9367A23C-6D40-1014-8BF0-9EFBF894F9D4:en_US

http://www.hasbro.com/monopoly/en_US/shop/details.cfm?R=9367A23C-6D40-1014-8BF0-9EFBF894F9D4:en_US

http://www.playcatan.com/info-contact.html

https://itunes.apple.com/us/app/catan-hd/id390422167?mt=8

http://www.catanshop.com/The-Settlers-of-Catan-P19C2.aspx

http://www.catanshop.com/The-Settlers-of-Catan-P19C2.aspx

http://www.ams.com/eng/Products/Lighting-Management/LED-Driver-ICs/AS1116

http://components.omron.com/components/web/pdflib.nsf/0/A59093552C8ED1C186257A5D0077B1D2/$file/W2RV004RM_0812.pdf

http://components.omron.com/components/web/pdflib.nsf/0/A59093552C8ED1C186257A5D0077B1D2/$file/W2RV004RM_0812.pdf


[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 CircuitBoard 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%20P-95%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 42013].

[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-wpa-password-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-computer- labyrinth-game [Accessed 2 2 2013].

-42-

http://boardgamegeek.com/boardgame/4746/dungeons-dragons-computer-labyrinth-game

http://boardgamegeek.com/boardgame/4746/dungeons-dragons-computer-labyrinth-game

http://lifehacker.com/5873407/how-to-crack-a-wi+fi-networks-wpa-password-with-reaver

http://lifehacker.com/5873407/how-to-crack-a-wi+fi-networks-wpa-password-with-reaver

http://www.mceproducts.com/knowledge-base/article/article-dtl.asp?id=11

http://1800recycling.com/

http://en.wikipedia.org/wiki/Polylactic_acid

http://en.wikipedia.org/wiki/Acrylonitrile_butadiene_styrene

https://en.wikipedia.org/wiki/Integrated_circuit

http://www.acrylite-shop.com/pdfs/3667a%20P-95%20Black%20and%20White%20sell%20sheet.pdf

http://www.acrylite-shop.com/pdfs/3667a%20P-95%20Black%20and%20White%20sell%20sheet.pdf

http://en.wikipedia.org/wiki/Acrylic_glass

http://www.sme.greenmfr.org/english/printed/printed.html

http://en.wikipedia.org/wiki/Printed_circuit_board


[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.acrylite- shop.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-ARM-Peripherals.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%20Design%20Specifications.pdf. [Accessed 21 2 2013].

[31] Triad Magnetics, “External Switchmode Power Supplies - WSU Series,” 3 2012. [Online]. Available: http://triadmagnetics.com/pdf/WSU-Series%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__sysclk__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-

http://asf.atmel.com/docs/latest/uc3b/html/twi_quickstart.html

http://asf.atmel.com/docs/latest/uc3b/html/group__group__avr32__drivers__gpio.html

http://asf.atmel.com/docs/latest/common.services.basic.clock.example1.evk1101/html/group__sysclk__group.html#ga242399e48a97739c88b4d0c00f6101de

http://asf.atmel.com/docs/latest/common.services.basic.clock.example1.evk1101/html/group__sysclk__group.html#ga242399e48a97739c88b4d0c00f6101de

http://triadmagnetics.com/pdf/WSU-Series%20datasheet%20(2012).pdf

http://triadmagnetics.com/pdf/WSU-Series%20datasheet%20(2012).pdf

https://engineering.purdue.edu/ece477/Homework/CommonRefs/Tutorials/PCB/PCB%20Design%20Specifications.pdf



http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf



http://www.semicon.toshiba.co.jp/info/docget.jsp?type=datasheet&lang=en&pid=TCS20DLR



http://www.acrylite-shop.com/US/us/acrylite-sheet/satinice-satin-ice-df-8ww9w0k5tzz.html

http://www.acrylite-shop.com/US/us/acrylite-sheet/satinice-satin-ice-df-8ww9w0k5tzz.html

http://www.mouser.com/ds/2/90/CLV1L%20FKB%201238-218261.pdf

http://www.mouser.com/ds/2/90/CLV1L%20FKB%201238-218261.pdf

http://www.mouser.com/ds/2/216/DC56-11EWA-43385.pdf

http://www.mouser.com/ds/2/216/DC56-11EWA-43385.pdf

http://boardgamegeek.com/image/756547/the-generals

http://boardgamegeek.com/image/756547/the-generals


[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__ix__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-

http://ajaxpatterns.org/Periodic_Refresh

http://asf.atmel.com/docs/latest/uc3b/html/group__group__common__services__delay.html

http://asf.atmel.com/docs/latest/avr32.services.dsplib.example.dsp32_iirpart.evk1100/html/op__ix__rand_8c_source.html

http://asf.atmel.com/docs/latest/avr32.services.dsplib.example.dsp32_iirpart.evk1100/html/op__ix__rand_8c_source.html

http://asf.atmel.com/docs/latest/uc3b/html/group__group__avr32__drivers__spi.html


Appendix A: Individual Contributions

A.1 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


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


A.2 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


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


A.3 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, 7-segments, 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


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 7-segment 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


A.4 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


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


Appendix B: Packaging

Figure B-1: Rendered Drawing

Figure B-2: Hex Divider Rendered Drawing

1


Figure B-3: Top View Measured Drawing

2


Appendix C: Schematic

Figure C-1: Microcontroller

1


Figure C-2: Hall Effect Network 0

2



3



4



5



6



7



8



9



10


Figure C-11: RGB LED Driver 0

11



12



13



14



15



16



17


Figure C-18: 7-Segment Driver 0

18



19



20



21



22


Figure C-23: Power Supply

23


Appendix D: 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


Figure D-2: PCB Top Copper View

2


Figure D-3: PCB Bottom Copper View

3


Appendix E: Parts List Spreadsheet

Vendor Manufacturer

Part No. Description Unit Cost

22.0 Qty

Total Cost

Digi-Key Toshiba TCS20DLR Digital Output Magnetic Sensor (H.E.)

0.312 145 $14.90

Digi-Key AMS AS1116 64 LED Driver 6.57 5 $32.85Digi-Key Atmel AT32UC3B064 32-bit AVR

Microcontroller

7.48 1 $7.48

Allied Electronics

Raspberry Pi Found.

Raspberry Pi Model B

Motherboard Device - Mini ARM PC

35.00 1 $35.00

Mouser Omron W2RF004RM LED Control IC

2.94 7 $20.58

Mouser Kingbright DC56-11EWA Red 2-Digit 7-Segment Comm. Cathode

2.08 20 $41.60

Mouser Texas Instruments

SN74HC151PW

8-Line to 1-Line Multiplexer

0.46 18 $8.28

Mouser Cree CLV1L-FKB 3 in 1 SMD LED

0.24 38 $9.12

4pc 4pcb N/A 18”x22” 2-layer PCB

485.00

1 $475.00

Amazon Tenda W311MI Wi-Fi Adapter 10.00 1 $10.00

TOTAL $695.15

1


Appendix F: FMECA Worksheet

Subsystem A: Power Supply

Failure No.

Failure Mode Possible Causes Failure Effects Method of Detection

Criticality Remarks

A1 Low 3.3 Voltage on board

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

A2 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, board does not power up, RGB LEDs flicker

Observation Medium May damage the Raspberry Pi

Subsystem B: Hall Effect Sensor Network

1


Failure No.


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


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


Low

B4 Hall effect sensor also triggers adjacent sensor

Pullup resistor network or multiplexer connections are shorted

Adjacent positions detect the same piece


Low maybe the resistor network is heating up and shorting the solder connections

2


Subsystem C: RGB LED Display

Failure No.


Criticality Remarks

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

Subsystem D: Rarity Display

Failure No.


Criticality Remarks

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

D2 7 Segment driver registers do not latch new data

SPI bus too noisy, driver failure, microcontroller load signal failure/timing

Rarity cannot be displayed on the board or changed

Observation Low

3


error

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.


Criticality Remarks

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

E2 The micro stops executing instuctions

External oscillator failure, noise on 3.3V power, software

Game board is frozen

Observation Low

4


5

Documents

EE 477 Final Report · Web viewA 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