Methodology

Overview

The design, construction, and delivery of the scoreboard was completed over a period of one and a half years and was broken down into six phases.

Design Phase

The design phase took place from 1 May to 14 June 2017. During this phase, the following tasks were accomplished:

· Brainstorming

· Project management documentation, which included the following items:

o Scope statement

o Gantt chart

o Bill of materials (BOM)

· Initial design approvals (Figure 5)

This phase provided the team with a solid direction and allowed for a dissemination of work amongst the team members. Each group member was provided with a specific area of responsibility that would guide their research and experimentation. Components were researched in order to determine the theoretical current draw for the system. An initial concept of the scoreboard enclosure was decided upon after brainstorming. Using the program SketchUp, an initial 3D model was created with the intention of being mounted on a stand to make the scoreboard easy to view (Figure 5).

During research, a large outdoor scoreboard used for cricket was discovered. This scoreboard provided a starting point for the selection of hardware to control the portable scoreboard. The cricket scoreboard utilized a microchip known as the TPIC6B595 in order to drive the seven segment displays. Using this project as reference, the team began to research this chip. The initial portable scoreboard electrical schematic included seven TPIC6B595 chips. The team later discovered a similar chip, the TPIC6A595, which has a higher thermal tolerance, and decided to use this chip instead. In order to control the TPICs, the cricket scoreboard team used an Arduino Uno microcontroller. James Schmelzer and Justin Roozen have worked with the Arduino platform in the past, so it was chosen to control the display and scoreboard logic. A library for controlling two seven-segment displays with an Arduino was available to download from the cricket scoreboard website. This library was used as reference and heavily modified in order to control the project LEDs. The Raspberry Pi was chosen to facilitate the wireless control, as documentation exists to configure the device as a router.

The audio system was planned to comprise of two speakers and a microphone, all combined under the name “PA” in the initial schematic (Figure 6). Due to the TPIC chips and LEDs running on two different voltages, 5VDC and 12VDC respectively, a 12V to 5V voltage converter was sourced. In order to integrate a power supply capable of running on 120VAC, the team sourced a 120VAC/12VDC 10A laptop power supply. The worst-case maximum current of the system was estimated to be 7.7 Amps, which is below the 10A current that can be supplied by the 12 Volt power supply. This calculation is based on the maximum current rating of all electrical loads in the system. Circuit protection was implemented after testing the components upon arrival.

Milestones

Design Complete

Purchase Phase

The purchase phase took place from 14 June to 16 June 2017. The main purpose of this phase was to consolidate the BOM and begin to purchase parts.

Milestones

Purchase Parts

Design Review and Mechanical Preparation

This phase took place from 17 June 2017 to 31 August 2018 and corresponded with the team’s CO-OP placements. In this phase, the team identified knowledge gaps and performed research that would be beneficial to the final build. In addition, the team had feedback from mechanical engineers and manufacturers in order to design (Figure 3) and construct a suitable final enclosure for the scoreboard. Fisher FBX44K speakers were sourced for the audio system.

Build Phase

This phase took place from 5 September to 16 October 2018. This phase included prototyping the final enclosure as well as confirming that all components work together properly. Prototype versions of the LED driver circuit boards (Figure 8) were created in order to verify the electrical design in conjunction with the Arduino and LED displays. The 3D model of the scoreboard was redesigned to remove components from the door, and structures were put in place to secure the speakers and display (Figures 9 & 10). Each LED seven-segment display was designed to be an independent sub-assembly in order to facilitate ease of repair. The team built a wooden enclosure to ensure the validity of the final circuit, programing and wiring designs. In addition, the final prototype (Figure 11) allowed for individual testing of components and measurements.

The current of each section of the circuit was measured in order to size protection accordingly. A face plate consisting of six rocker switches, two USB ports, a volt meter, and a cigarette lighter was installed. The team decided not to power the cigarette lighter to prevent the user from exceeding the power supply current rating. A reset button was connected to the Arduino in order to reset the display. Through the addition of a relay to control the top or bottom LED indicators, the number of TPIC chips used was reduced from seven to six. The following currents were measured throughout the prototype system. The Canadian Electrical Code was consulted to select fuse sizes.

- Measured current of all 35 bar LEDs: 2.516A

- Measured current of all 9 ring LEDs: 664.2mA

All LEDs are fused together at 5A.

Audio system current: 132mA per speaker and 150mA from the Bluetooth module for 414mA. The audio system is fused at 1A.

The Arduino Uno draws approximately 50mA, and the Raspberry Pi draws 80mA. These are each fused at 1A as it is the smallest standard fuse size available for the fuse box used.

The TPIC6A595 chips only draw 5mA each. All six are fused together under a single 1A fuse.

The switch module contains two USB ports, rated at 1A and 2.1A max current draw. They are fused at 5A.

The voltage converter has a rated maximum current draw of 5A and was fused at 5A.

A final electrical schematic was created in the program DipTrace to reflect any changes made to the design since the beginning of the build phase (Figures 12 & 13).

After verifying the designs of the LED driver boards, the design was revised. This design was a single board with two jumpers to change between controlling two seven-segment displays or 1 seven-segment display and the circle LEDs. The final driver board was designed using DipTrace (Figures 14 & 15) and was sent to Alberta Printed Circuits to be professionally etched. After the prototype was deemed functional, a wiring diagram was created to map the layout of the components inside the enclosure. The intent of the wiring diagram was to provide a smooth transition from the prototype to final enclosure.

Milestones

Circuit Prototype Complete

Software Prototype Complete

Wireless Prototype Complete

Mechanical Prototype Complete

Final Prototype Complete

Testing Phase

This phase took place from 16 October – 30 November 2018. The phase consisted of testing the prototype, confirming the final layout of the control shelf, final documentation and the testing and construction of the final enclosure. The overall current of the system was measured at 3.93A (Figure 16) while all LEDs were on, the audio system was powered, and both USB ports were charging smart devices.

The professionally etched LED driver printed circuit boards were soldered (Figure 17) and integrated into the final assembly. Two boards were configured to control two seven-segment displays. A third board was configured to control one seven-segment display and nine circle LEDs. Three extra LED driver printed circuit boards were ordered as spares for replacement if a failure occurs in the field.

The testing of the project’s functionality was conducted by Greg Loucks, Luke Marche and Abed Moussa. The results of this testing are included below. To summarize the results of these tests, an error was discovered that only occurred when the Wireless device sent a “home score” value of zero; the Arduino would receive the wrong message and display unintended values. The issue was caused by two separate bugs. The first bug was on the Raspberry Pi when it sent the data word to the Arduino over the UART. If the most significant bit of the data was zero it was sending an incorrect message. In order to fix this issue, a “Start” nibble was added to encapsulate the word and ensure that the correct amount of data was being sent (Figure 18). The second bug was in the Arduino’s serial communications section. The function “Serial.available” was documented as returning the number of bytes received. However, through testing, it was determined that it actually returns the number of bits received. This meant that words that were too short were being accepted, and the leftover data in the ring buffer was being used by the Arduino to update the display. In order to fix this issue, the message in the Arduino’s buffer is checked to ensure it is 31 bits long.

Milestones

Circuit Testing Complete

Software Testing Complete

Wireless Testing Complete

Final Testing Complete

Final Product Complete

Report Phase

This phase took place from 30 November – 13 December 2018. The phase includes the completion of final documentation and delivering the final product (Figure 19) to the customer.

Milestones

Final Presentation Complete

Final Report Complete

Product Delivery

Individual Section

In the Capstone 1 course, the group performed initial brainstorming and broke the project into four sections:

Electrical Design – Thomas Walden

Mechanical Design – Justin Vaughan

Programming – James Schmelzer (Arduino UNO) and Justin Roozen (Raspberry Pi)

Project Management – Team effort, coordinated by James Schmelzer

During the course of the CO-OP term, James Schmelzer ensured communication was maintained between group members and followed up with the progress of individual research tasks.

James Schmelzer:

James Schmelzer’s contributions to the project include:

- Distributing tasks to team members and ensuring task completion

- Organizing team meetings and ensuring group participation

- Providing working facilities for construction and testing

- Updating project management documents and/or tasking a team member to update documents

- Coding the Arduino UNO to allow for manual control and basic functionality of the project

- Writing the operations manual and test protocol

- Assembling and aligning the LED displays for the final construction of the scoreboard

After the construction of the test rig (2 LED segments) by Justin Vaughan, the Arduino code was conceptualized. The Arduino’s role was to control the display, provide manual control and accept communications from the Raspberry Pi for wireless control. The code was developed with the SOLID principles in mind as well as future portability between different hardware iterations and game systems. In order to view the code in greater detail, please refer to the project website. With this in mind, the code was separated into six files, each with a specific purpose:

Main.ino – Program start with hardware specific functions

Initialize.c – Initialization functions and holds a global structure, which contains the displayed values

Display.c – File for integration with the TPIC6A595 drivers

Baseball.c – Baseball game logic

Com.c – File to accept predefined communication word between Arduino and Raspberry Pi

Buttons.c – Input logic for Switches and buttons

The first iteration of the code utilized a “three-button” system of control for the scoreboard and was used to test the function of the TPIC chips and LED segments. This was determined to be unwieldy for the customer and was replaced with the two button/five switch configuration in the final design. For documentation, a variation of the “doxygen” style was used to allow for easy readability and to provide the ability for software documentation to be printed out if requested. Finally, the code was reviewed by Thomas Walden for commenting and spelling errors.

After the completion of the electrical and mechanical designs by Thomas Walden and Justin Vaughan respectively, James Schmelzer constructed a full-scale wooden structure for the scoreboard prototype. The team used this prototype to verify the scoreboard designs, plan the final wire harness, and ensure that all separate sections integrate together properly before transferring the internal components to the final enclosure.

During the transfer of components from the wooden prototype to the final enclosure, James Schmelzer worked in conjunction with Justin Roozen to line up and wire the LED displays. This process was vital, as each LED segment and circle LED were lined up with the corresponding openings on the display surface’s decal.

In regards to additional documentation, James Schmelzer wrote an operation manual and a test protocol. The operations manual describes the use of the scoreboard, the logic behind manual controls, and the use of the wireless device. This file has been added to the scoreboard wireless device for the user to refer to. The test protocol was written in order to ensure that the code worked as expected. It ensures that edge cases were tested and that one feature does not interfere with another. The most recently completed test protocol is stored on the project’s website for future reference.

Thomas Walden:

Thomas Walden’s contributions to the project include:

- Researching and testing of electrical components

- Designing and documenting the electrical schematic

- Updating the electrical schematic to correspond to design changes

- Designing and testing the LED driver circuit boards

- Soldering

- Wiring the final scoreboard (TPIC boards and display wiring, Figure 21)

- Troubleshooting electrical connections to microcontrollers and LED driver boards

- Measuring and calculating the currents across the system

After the initial brainstorming sessions during the Capstone 1 course, a rough draft sketch of the electronics was drawn. The design was revised and recorded using the program “Multisim” in order to display a clear schematic on the team website. The design was updated several times during the project as new devices were added to resolve design updates. The final electrical schematic was drawn in the program “DipTrace” and includes every electrical component in the final build of the scoreboard. The LED driver circuit boards were also designed using “DipTrace”. The first design utilized seven TPIC chips, which was reduced to 6 by using a relay to control the LEDs for displaying top or bottom of the inning. Each driver board used two TPIC6A959 ICs in order to control two seven-segment displays, or one seven-segment display and 9 round LEDs. One design capable of performing either function (two displays or one with circle LEDs) was created with the ability to swap version type by adding or removing two jumpers. The prototype driver boards were soldered to perforated board with wires to connect all of the LEDs as well as signal wires from the Arduino Uno to control the TPIC chips. Once the prototype driver boards were verified to function properly in the prototype scoreboard, the designs were sent to Alberta Printed Circuits to be professionally etched. The LED driver printed circuit boards used a two-layer layout to reduce the overall board dimensions. Screw terminals to connect wires were soldered to the circuit boards instead of soldering the wires directly to allow for modularity in case repairs to the scoreboard are required.

Initial current calculations were performed using the worst-case currents listed on the datasheets for the components used in the design. For components with no listed current rating, similar component current values were used in the estimates and then verified through measurements when the components arrived from order (Figure 22). Overall current measurements are made with all LEDs on in order to obtain the highest current draw possible. A document was created listing the current draw of each component for Justin Vaughan to perform calculations to select fuses for device protection.

Justin Vaughan:

Justin Vaughan’s contributions to the project include:

- Purchasing

- Updating bill of materials

- Formatting the project website

- Designing the mechanical assembly

- Laying out the electrical wiring

- Mounting electrical components and mechanical assemblies

- Designing circuit protection

- Troubleshooting power and terminal block connections

During the early stages of the project, Justin Vaughan 3D modeled the mechanical concept using the program Solidworks. Using the designs conceptualized during Capstone 1, the team researched components to be used for the scoreboard. The dimensions of the chosen components were used to create a real-scale 3D model of the electrical layout within the enclosure. A test fixture, comprised of two seven-segment displays, was then constructed by Justin Vaughan for James Schmelzer to verify the initial code. This test fixture also enabled Thomas Walden to test the LED driver prototypes and verify electrical designs.

Once the scoreboard enclosure was designed to its second revision, over the time period from July 19, 2017 to November 4, 2018, all project material was purchased. On August 22, the mechanical drawing was sent out to be manufactured, and a wooden prototype was constructed to confirm the internal layout and to test the entire system. While constructing the prototype, a wiring diagram was developed with a detailed wiring list to document every connection. A uniquely identifiable, alpha-numerical, wiring labelling convention was created to identify every wire in the system. For example, “SOUT1.2” would be defined as functional (SERIAL OUT), next logical (FIRST), next sequential (SOUT1.1) before and (SOUT1.2) after electrical terminations. When the metal enclosure arrived, work began to weld, assemble, mount and paint all the mechanical parts. After final paint touch-ups, a dry fit and installation of all electrical and mechanical components on the shelf and control console was conducted (Figure 24). Lastly, the wiring label methods were put to the test by integrating the wiring from the prototype to final scoreboard enclosure before conducting final testing.

Justin Roozen:

Justin Roozen’s contributions for this project include:

- Setting up the Raspberry PI as a wireless access point

- Enabling communication between the PI and the Arduino

- Creating a web page for wireless control of the scoreboard

- Running the wiring for all aligned LEDs on the final scoreboard

- Ensuring the team website is up to date

In order to set up the Raspberry Pi as a wireless access point that any wireless device could connect to, several configuration files needed to be changed, which included changing the DHCP and HOSTAPD configuration files in the Pi to give it a static IP address, as well as giving the Raspberry Pi a unique SSID and passphrase. Also, configuration has been done to ensure that the Raspberry Pi will only provide a limited number of IP addresses to the users, as well as having a limited time that those users can hold their assigned IP addresses. All these features combined allow the Pi to work as a rudimentary wireless router with a unique id and password, which prevents unwanted users from connecting to the scoreboard. Serial communication is used to enable communication between the Raspberry Pi and the Arduino Uno, which is achieved by running a Python script on the Pi that utilizes the serial library to transmit a formatted message to the Arduino across the UART pins. This script contains data validation and error checking to ensure that only valid messages are delivered to the Arduino. The message being delivered is created using bit-shifting in order to have it conform to the pre-designed standard created by James Schmelzer.

The Arduino program then interprets and decodes the word in order to control the scoreboard logic and update the display. In order to create a web page for the wireless control of the system, Flask is being used to create a Python based web server that allows for simple integration with the script written for serial communication to the Arduino. The web server is configured so that when a user connects to it, the user is routed to the web page stored on the Pi. The web page utilizes web forms known as “WTForms”, which allow various fields to be used for the user to input values to control the scoreboard. Validators are used in all fields where the user can input data to ensure that data is not being sent without all fields having valid inputs. When all fields have valid inputs, the web server retrieves all the field data and sends it to the script, which processes the message for delivery to the Arduino. If any of the fields are invalid, no message is sent in order to prevent incorrect data from being displayed.

Transferring all the components from the prototype enclosure to the final enclosure was a meticulous and time-consuming process. Ensuring that all the LEDs were aligned and wired correctly is a large component of assembling the final product. The aligned LEDs are mounted on corrugated plastic, and on modular segments to ensure ease of any future troubleshooting or maintenance. The wires to power the LEDs are routed through holes in the corrugated plastic that are drilled in locations where the wires are not visible to the user, and allow for ease of assembly. Content updates to the team web site are performed as per the requirements of COMM-3070 and MGMT-5078.