Table of Contents Executive Summary 2



Download 471.88 Kb.
Page2/17
Date31.07.2017
Size471.88 Kb.
#25812
1   2   3   4   5   6   7   8   9   ...   17

1.2 Goals and Objectives

1.2.1 Umpire Device


Umpires are an extremely vital part of regulating baseball in making sure that the game progresses in a normal fashion and that all plays enacted by the players are legal and safe. One of the tools that an Umpire has is his handheld indicator. This simple device allows him to keep track of game play. On a regulation umpire device balls, strikes, and outs are kept track of. All of this information is also recorded, however, by the coaching staff and by the trained score keeper in upper-level divisions of little league. Several of the goals of this project can be completed through digitizing the umpire indicator. The data of balls, strikes and outs can be limited to only recorded once from the actual handheld device. This improves efficiency of the scoring process by not requiring the coaching staff and the scorekeeper from writing by hand duplicate information. This reduces what the coaching assistants and scorekeepers are responsible over, reducing the training time of these jobs. Creating a digital umpire indicator fully able to display all current data of balls strikes and outs is required for this project. This handheld device will have the ability to wirelessly send the information logged from the device to the main database for scoreboard updates and data processing. Later in this document the research on how to best select the working components of this digitized umpire indicator will be discussed in more detail.

1.2.2 User Friendly


To successfully complete this project all aspects from the umpire indicator to the fan application must be easily understood and able to be fully utilized in a minimal amount of time. The currently implemented system of scoring and logging of data requires greater than 100 hours of training to know how to properly use the system. This senior design project aims to create a digital data acquisition system that is straightforward and quickly uploads information into the database. The umpire indicator must be simple to operate and the functions of this device and the displayed information easy to understand. The coaching application must be easy to navigate and all information previously written on the scoring card accessible in the application. The fan application also needs to be easily understood with all viewable data laid out in an informative and easily read layout. The menus of the fan application should also be easily navigated so that all of the information stored in the database on specific players and teams is accessible on the device.

1.3 Requirements


Due to certain hardware limitations of the devices used in the proposed system, certain system requirements must be followed for the successful execution of the system on the whole.

1.3.1 Umpire Indicator


The umpire device that the group is attempting to digitize has many requirements to fulfill the functions of the simple analog indicator. The analog indicator has rotary wheels to indicate the value of balls, strikes, and outs of the current player and half-inning being played. 2.6 Figure 1 shows an example of the currently used umpire indicator with relative measurements. This umpire indicator has a four number wheel for strikes of 0 – 3. Upon rolling the wheel to three outs the umpire knows to call the batter out. The next wheel on the umpire indicator is the ball category. There is a range of 0 – 4 on this wheel that when the player is pitched four balls the umpire can allow the batter to walk. The last wheel on the handheld device indicates outs. As described earlier in this document there are three outs per half inning and upon getting three outs the opposing team is up to bat. This device by keeping track of this information aids the umpire in knowing the progress of the game. The digital umpire device will display all of this information to the umpire via three small 7-segment displays. The umpire will be able to increment the balls, strikes and outs of that inning by the pressing the appropriate push button for that function. This will then progress the number on the 7-segment display as if the umpire had spun the dial of the traditional device. The requirements for wireless transmission and specific components are explained further in the below sections.


1.3.1.1 Microcontroller


Since the umpire holds this device in his hand it is ideal to have it be battery operated. This means that the microcontroller must be sufficiently efficient to run off the same set of batteries as all of the 7 segment displays and wireless technology. An added bonus to the microcontroller requirements is a low power or sleep mode to aid in battery life. The microcontroller will also need to be easily interfaced with a wireless transmitter to send what the umpire has selected to the database network. Due to the data being transmitted being of a fairly simple nature only a few pins will be needed on the microcontroller for this function. This is a very important function though, with all the pins needing to be digital output pins that connect from the microcontroller to the wireless device. For the umpire to be able to read and modify what values are stored in the microcontrollers memory, 7 segment displays are going to be needed with push buttons. These pins will need to be available on the microcontroller for all the LED displays to work. For all three of the LED displays to work an ample number of pins will need to be available in a digital or analog format whichever is called for by the displays. Another set of three pins will need to be available for the buttons to be fully functional. Problems with the push buttons are that when the buttons are pressed, there is a possibility of false triggers of these buttons. The microcontroller will need to have a software debouncing function to prevent false triggering and potentially irrelevant values. Ease of programming of the microcontroller is also very important. The microcontroller must only require a few pins to program or come with a suitable programmer to allow for easy initial programming and if needed secondary programming to correct issues. Having the programming language to be something simple to program like c programming instead of something like MIPS or other version of assembly is vital as the programming greatly simplifies to write and debug.

1.3.1.2 Displays and Push Buttons


To maintain the ability to monitor the number of balls, strikes and outs, a method of recording and remembering the values of these variables needs to be established. This is best done through changing the click wheels to a display screen and placing push buttons in the device for the umpire to press to increment the values of the three variables.

1.3.1.3 Wireless Transmitter


The wireless transmitter in the umpire device allows for streamlining data acquisition directly to the database for further processing. There are innumerable possibilities for how to transmit this data from the device to the database with more detail of what was specifically chosen in the research and design parts of this document. The important things to consider are whether the chosen chipset has the required range to work from where the umpire stands to where the receiver is located at the data storage location and whether a receiver will need to be designed and built or whether it will be built in to another system of this design project like the coaching tablets. Another important factor is whether the chip is suitable to run off of the same battery that the whole device runs off of. Battery life and form factor for how much space the chip will require and the energy consumed over time by the chip required extensive research as a chip too large or requiring too much power could reduce the effectiveness of our design.

1.3.1 Coach Application


Since the device on which the coach application will be running must interact with the other components of the system, it has certain requirements that must be met in order to assure this communication is possible in addition to any other physical requirements the application may have.


  • The device on which the coach application will be running must feature blue tooth connectivity: The umpire indicator will be communicating with the coach application through a blue tooth connection. In order for this communication to be possible, the hardware device must support such connectivity. Additionally, the hardware device must be within working range of the umpire indicator. This range limitation provides both a quick and easy way for umpire inputs to be sent to the coach applications in addition to limiting the input only to the coaching staff within the dugout.




  • The proposed software must never prevent the use of the built-in Android buttons: Built-in Android buttons such as the Home and Back buttons shall never be prevented from performing their intended functionality either due to method overrides or due to the application failing to respond in a timely manner.




  • The device running the coach application must have internet connectivity at the point of in-game use: The stat-tracking system relies heavily on uploading of statistics into an internet database, which cannot be accomplished without a static internet connection at the time of use. This may be either connection over a cellular data signal or over a nearby wireless internet router depending on the location, although a tablet device capable of cellular data transmission and receiving would be ideal as it works anywhere covered by the particular provider.




  • The battery on the device running the coach application must be able to last through the length of at least one full-length game: The legitimacy of the system would be compromised if the application were not able to record a full game’s worth of statistics due to the length of the tablet device’s battery life.



1.3.2 Fan Application


Since the device on which the fan application will be running must interact with the other components of the system, it has certain requirements that must be met in order to assure this communication is possible in addition to any other physical requirements the application may have.


  • Connect to a database to acquire information for the user: This is the main requirement of the app. It needs to display the information stored on a database so the user can view it. Without the ability to connect to a database the app would not be able to acquire any information.




  • Display information for current games, recent games, teams, and players: The main purpose of the application is to provide users with up to date information on current games and view the team’s and player’s stats all in real time.




  • Be fast and close to real time: To keep the user up to date the application needs to be able to connect to the database and retrieve information as fast as possible providing the user with real time updates.




  • User friendly: The user needs to easily be able to find any game, team, player or any other information as easy as possible. If the interface is not user friendly the user will become frustrated and no longer use the app.




  • Show the score, outs, balls, strikes, inning and plays of a game: The user needs to be able to view all the important data about a game just as if they were there or watching it on TV. These are the necessities of any baseball game to be able to follow what’s going on.




  • Show a team’s name, league, coach, record, players, and any other stats: This is the required information that needs to be displayed for a team. Teams have names and all their players should be easily found here.




  • Show a player’s name, age, team, picture, position, and all of their stats: The player’s page should act just like a baseball card, displaying all their information and stats as well as a photo.




  • Allow a user to search for a game, team, or player: To be able to easily find what the user is looking for they should be able to search the database for a game, team, or player and receive results within a reasonable amount of time depending on the speed of their internet connection.




  • Allow the user to follow a game, team and/or player: Once a user finds a game, team, or player they should be able to easily go back to that page from anywhere in the app.




  • Usable on a smart phone with an android OS: The application should be able to run on any android phone with no issues and perform equally well despite the platform.



1.3.3 Database


With the extreme amount of baseball stats, game, player, and scoring data, a crucial aspect to this design is storing and organizing all of the data in an accessible, fast, and convenient manner. To that end, the database is the driving factor of data access performance. The database will be required to complete two overall tasks:  Storing all of the data types for current games, past games, and overall team data. Additionally, the database must be optimized well enough to handle hundreds of simultaneous data access, both reads and writes, while maintaining consistent and reliable speeds. To meet these requirements, it is necessary to model the database in a manner to focus on specific data types that will require more intense activity, and isolate data values that require less usage. Designing these data types based around baseball statistic activity will allow the database to prioritize more important values.


  • The database must organize statistic variables by priority in relevance to optimize access speeds:  On the most basic level, the database is required to handle and store game data, player data, and overall team data. Game data are variables changing during while a baseball game is in play. This includes scoring data such as balls, hits, runs, outs, pitches, etc. These data values are constantly changing, and are crucial to the game currently being played. Additionally, each game being played will always have different values for each of these variables at different times, and each game’s data must be stored independently from the other games. Player data includes player stats, which are compounded from each individual game (data occurring within the game data category) and summarized for each individual team member. Similar to game stats, player data is also retrievable at any time, as they are included within the team’s roster stats. Player data includes variables such as batting averages, pitching averages, etc. This requires player data to be updated simultaneously with game activity data, as both database categories share similar variables. Since these must be independent databases, this means both will need to be maintained concurrently, with constantly updated data. The final database category is team data, which includes the overall statistics for the team. Team data includes overall stats summarized from each individual game. This data obviously is not crucial to the current game being played, so its update priority can be yielded to live data priority. This category is mostly used for team analysis and ranking.




  • The database must organize and manages current games, as well as previous games, by creating backups and storing data outside the currently active database:  Coaches and their teams can benefit from past game data, using it to analyze their performance and view individual statistics. This presents a new task for the database to manage. Once a game is finished, the data is no longer being actively updated, this means the data can be stored elsewhere to free up space within the database for new data. After a game’s completion, the database will be required to move the game’s data out of the live database, and into an inactive state, through either a new (not directly accessible) database, or by creating a backup outside of the database. Since the data will need to be readily available for analysis by the teams, it’s best for the data to be copied into an archived database, which is viewable, but not directly modifiable (read-only state) by the mobile device applications.




  • For peak performance, the database’s main responsibility is reacting to input and returning values as quickly as possible:  During games, the database is being repeatedly accessed by spectators, coaches, and the umpire. For little league games, the total clients can be several hundred, in high use scenarios. This means the database is required to handle reads and writes from hundreds of clients concurrently. Given that the database is being built upon pre-existing software, most of these access optimizations have occurred within the software’s design. Despite that fact, it still requires the database to be organized in such a manner to reduce access times. This includes the amount of databases being simultaneously accessed and the size of each independent database (amount of variables, calculations, and size of data). Typical baseball statistics and coach requirements dictate which variables will be necessary for each game and player. To boost database performance, the organization of the databases themselves and chosen variables in each assigned database will determine speed outcomes. Most baseball integers are small integers, along with a few decimal-based averages. Calculations within the database are minimal, with the averages only requiring two variable inputs. Data accesses from the clients will mostly occur in specific groups; for example, the entire collection of a player’s stats can be accessed within the same record. This means information queries about the game being played, or a specific player, acts in a spatial manner in the sense that the most requested data will be available in a series.




  • The database must support verifiable client access from non-local sources:  Multiple sources include the coaches writing data, as well as the spectators reading data. These connections being made wirelessly through Droid-based devices, requiring the database to handle these requests. Because the database contains all of the statistical data, limitations must be imposed on individual clients to control their access capabilities. Verification must occur for coaches and umpires to ensure that only they are given write privileges, otherwise a security concern for spectators might allow them to control data within the team and game stats.




  • Wireless access must be permitted, and designed in a way to minimize network bandwidth:  Since all critical accesses will occur via wireless device, this introduces a new complication to database speed optimization. Not only does the data have to travel across a wireless network, the database must also handle multiple wireless requests in a way to minimize latency and network congestion. A network interface such as a PHP server or a web server would help as a filter between the wireless accesses and the database.




  • If information is not retrieved from the database within an acceptable time limit, the connection will time out: Rather than continuing to try and access the online database





Download 471.88 Kb.

Share with your friends:
1   2   3   4   5   6   7   8   9   ...   17



The database is protected by copyright ©ininet.org 2024
send message
    Main page
major leagues
entire structure
interface used