Little League Baseball Statistics Tracking System

Corey Cowart, Sean Martin, Nicholas Rimer, Brian McCauley

School of Electrical Engineering and Computer Science, University of Central Florida, Orlando,

Florida, 32816-2450

Abstract — The objective of this project is to design and implement a four pronged statistics tracking and presentation system for Little League baseball players. By using coach input into a tablet application to submit on-field events in real time to an online database, the solution is expected to improve accurate statistic collection not only for personal use but also to aid in the drafting of new players into the upper leagues. Additionally, the solution will allow the players’ fans and family to better connect with the game by being able to follow games in real time from any android mobile device.

Index Terms — Database Systems, Radio Communication, Mobile Communication, Software Design .

I. INTRODUCTION

Little league baseball scoring methods have widely remained unchanged, using a basic system involving the coaches manually tabulating data with pen and paper, and more complex statistics being completely unrecorded, due to lack of proper means to do so. Enhancing the ability of the coaches to effectively manage and record these statistics, while allowing umpires to more fluidly input game data, will not only allow coaches and players to better analyze their team statistics, but also enable fans of their little league teams to have easier and more available and immediate access to game and team statistics. Providing a seamless experience to umpires, coaches, and fans, will not only allow more statistical data to be recorded and managed, but allow more time to be focused on the game while doing so. Streamlining this process also provides more feedback for the umpire, allowing the umpire to observe player changes in a quicker manner. Additionally, these changes will be immediately available to the fans, allowing them to stay informed with the current team roster and on-field events.

Implementing a mobile design using Android-based devices allows for a more customizable, user-friendly interface, for each user to access and manipulate data in ways most convenient for them. Coaches can easily control their team rosters, player positions, and line-ups in

an electronic interface, and immediately return those results to be viewed by umpires and fans on their own devices. This system also provides much less overhead for the coaches, as managing their entire team using one device, as opposed to standard roster lists and scoring sheets. Currently, spectators of a little league baseball game only receive feedback via the scoreboard, and whatever calls the umpire is actively making. Implementing this data, and more, into a database and allowing mobile devices to access and display the information, will give fans immediate access to up-to-date statistical data in ways that cannot currently be implemented using standard practices. This opens a brand new aspect of interactivity to the fans, allowing them to become more involved with the game, and providing feedback to each player’s performance. For little league parents, this is an exciting concept, as none of these advanced statistical figures are currently being stored, let alone accessible during games.

Figure 1: A baseball score sheet that the coach application is intending to replace.

In addition to increasing the amount of readily available data and improving organizational efficiency with umpires and coaches, having all of the data stored into an online database readily available to any user with an android device creates a powerful tool to allow spectators and coaches alike access to a berth of previously untapped resources. Additionally, introducing these new services into little leagues will improve the entire structure of the game, enhancing the way coaches manage their teams, the

way umpires issue game calls and parents and players gauge their major league potential.

II. SYSTEM DEFINITION

The system itself will consist of 4 major undertakings:1) A tablet application to be used by coaches that allows them to easily manipulate their current roster, enter data of all on-field events during a game in real time, and provide access to view player and team data from around the league for game preparation. 2) A wireless umpire device that will upload pitch and game state data through Bluetooth directly to the coach application, ensuring accurate game flow. 3) An Android application targeted at fan use that allows anyone to be able to look up player’s statistics on any player utilizing the system in addition to allowing them to follow currently occurring games in real-time. 4) An online database that will store and sort all uploaded information as needed as well as provide it is stored data to the coach and fan applications when requested.

A. Umpire Device

To complete this project successfully all aspects from the umpire indicator to the fan application must be easily understood and able to be utilized fully in a minimal amount of time. The umpire indicator must be simple to operate and the functions of this device and the displayed information easy to understand.

Figure 2: A typical analog umpire hand indicator that is used to keep track of games.

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 listed below:

Has the ability to run off an internal battery for greater than two games.

Maintains general dimensions of existing design, maintaining that it can be handheld.

Wirelessly connects at no less than 30ft from the database connection.

Display(s) to show at minimum balls, strikes and outs.

Push buttons to increment the counts of balls, strikes and outs on the device.

Accidental push button rejection coded into the device.

Displays able to show digits 0 through 4. Constructed on a PCB based design. Power on/in Reset LED indicator. Push button for resetting device. Push button for automatic next batter setup.

B. Coach Application

The coach application is the point in the system from which all of the game play data and players rosters will be loaded into the online database in order to accomplish all of the needed operations, the follows objectives were formulated:

Will be implemented on an Android tablet device. Will feature a home screen that allows quick and easy

access to all other facets of the application. Will allow the coach to view and edit the roster to

their current team. Will allow for the adding of a player to the roster

who has played previously for a team that utilized this stat-tracking system to carry over all previously recorded stats recorded for that player.

Will have an interface through which a coach can create a starting lineup for an upcoming game.

Any change in the umpire device will be reflected instantaneously on the in-game interface.

Statistics will be uploaded to the database in real time as they are being recorded.

Coach application will be able to accurately record all information that is recorded onto the currently used log books.

Coach application will have the ability to access specific team data outside of an occurring data to use in preparation for future games.

As mentioned previously, the goal of the coach application is to digitize and improve the previously mentioned dugout score sheets. Implementing the above features in a usable and intuitive way will allow that to be done.

D. Fan Application

The fan application is being developed for the fans to view their favorite team’s information such as stats, standings, and individual player stats within that team’s roster. As such, it needs to be user friendly and wirelessly capable. Below are some of the goals in the development of this software:

The fan Application will be implemented on the Android O platform.

The fan application will be able to use wi-fi for access to the online database when no cellular data is available for use.

The fan application will have an interface through which they can access individual player data by being able to search the database for a given player name.

Fan application will be able to find and display all currently occurring games, and be able to select which one they would like to follow in real time.

The fan application will only be an interface through which users can view the multitudes of data that will be stored in the online database. It will not have access to change or write anything to it similar to that which the coach application will have.

E. Online 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.

The database must organize and manages current games, as well as previous games, by creating backups and storing data outside the currently active database.

For peak performance, the database’s main responsibility is reacting to input and returning values as quickly as possible.

The database must support verifiable client access from non-local sources.

Wireless access must be permitted, and designed in a way to minimize network bandwidth.

If information is not retrieved from the database within an acceptable time limit, the connection will time out.

For organizational purposes, each team will have its own database entry

The database must manage and migrate new statistical data from an existing game to total team record data.

III. DESIGN

A. Umpire Indicator

All functions of the Umpire device will be controlled, stored and transmitted by processes of the microcontroller to the peripheral equipment in this design. The chip that best met these requirements is the PIC24HJ128GP502 from microchip.com and will be used in this design. Some of the most noted features of this chipset are listed below:

16-bit architecture that has CPU speeds of 40 MIPS Program memory of 128 KB which will easily fit our

program 21 I/O pins for the displays and push buttons of the

project Low power management modes to increase battery

life C compiler optimized instructions

The power requirements for this microcontroller are specifically stated in the data sheet and reference material for the PIC24 microcontroller. The supply voltage range for this chip from the data sheet is 3.0V to 3.6V.

The microcontroller needs to send the appropriate 4-bit number to each of the displays for them to display this for the end user. This is easily accomplished in C with printing a register value to that specific display through its designated output pins. Another section in the software for the microcontroller will be the pushbuttons on the device. There are two different kinds of pushbuttons on

the device for the umpire to utilize. The first are the buttons for incrementing the values of balls, strikes and outs on the device. This will be handled as an interrupt function in the software. When the microcontroller sees that the button has been pressed for an incrementing of any of these values the device will call up that register increment that register if it is below the allowed value or reset if above the allowed value of balls, strikes and outs. The interrupt code will next update the display and send the updated value to the transceiver for wireless transmission.

Figure 3: the 7 segment displays connected to the pic microcontroller.

The second type of button on the umpire indicator is the special function buttons. These special function buttons are for resetting the device if for some reason the values get inappropriately incremented and the second special button is for next batter. These two buttons like the increment buttons will be interrupts in the software. The reset button will clear the register containing the counts of balls, strikes and outs, allowing the umpire to reset these values before resending the data to wireless. The next batter button is for the convenience of the umpire and the database storage method. When the next batter button is pressed the values of the registers will be sent to the Bluetooth chip for transmission with a special value that tells the database that this player is no longer going to change any of his or her data and a new batter is going to have their data altered. The microcontroller will then reset the values of the registers back to zero for the new batter, resetting the displays back to zero.

The most effective way to utilize the 7-segment displays is to use an integrated chip as the driver for the 7-segment displays. The BCD to 7-Segment Display driver is the perfect solution. The 4511 was chosen for this use. As shown from its specifications, it can be powered with a supply voltage of 3V to 15V. Changing the input voltage changes the amount of current the chip can supply to the

displays at any given time and changes the efficiency of the chip. So much of this project will be powered with 3.3V so it was decided to also power the 4511 with this voltage.

For this design we will be using pins 6,7,14,15 and 26 for the five pins needed for the five switches. To implement the pull-up resistors so that the push-buttons will properly signal the microcontroller, the group has designed the pushbuttons to be connected to ground and to the appropriate pins on the microcontroller. Next 3.3V is supplied from Vdd to the pins on the microcontroller through an internal pull-up resistor to limit current to the microcontroller. A de-bouncing function was put into the code for the microcontroller to avoid the ringing of the buttons and recording of false information. For this design, the group will have the microcontroller constantly looking at the pushbuttons and comparing the current recorded value to the value that was recorded 30mS before

Wireless communication with the coaching tablets will be implemented using the BlueGiga WT12 Bluetooth chip. The WT12 has the ability to connect to all current mobile devices including our tablet and appropriately allows upload of the data to the database. The Vdd pin will be supplied with 3.3V, as are many of the other circuits in this design. Ground is supplied to the chip at the several Vcc pin connections. With these two pins connected the chip will power on, however, this Bluetooth chip is very sensitive to power supply fluctuations. Knowing the chips sensitivity, decoupling capacitors and weak pull-up resistors are inside the WT12 to protect itself on all needed pins. This aids stability of the chip and aids in noise rejection in the wireless transmissions. The next required sets of pins are the data transmission pins. These pins are labeled RxD for the receiving pin and TxD for the transmission pin of the Bluetooth chip. Also there are the CTS and RTS pins that need to be connected. The CTS pin is for the Clear to send command. This command allows the WT12 to transmit the needed data when this pin goes low. The RTS pin is the flow control output of the WT12. These pins are internally controlled because the data is buffered inside the Bluetooth module and so will be connected to each other. This Bluetooth module also has the ability to use Bluetooth to transmit audio, this will not be used for the purposes of this project and these pins will not be connected. The fulfilled purpose of this chip is that the data stored in the microcontroller will be sent to the coaching app of a serial connection.

Figure 4: The BlueGiga WT12 Bluetooth module used in this

project.

B. Coach Application

The coach application is the point in this system that drives all of the data input into the database. It consists of 3 main functions/interfaces: pre-game, in-game, and post-game. The main function of the pre-game manager is for the user to be able to view and manage the current roster to his team. It will contain a list of all of the players that are currently on his team, which will be stored in a local SQLite database so that the online database does not need to be queried every time a coach would like to view his roster. Although these data structures are stored locally, any additions or changes in the local database will also update to reflect these changes in the online database. This will keep the online database up to date, allowing

Figure 5: A simple class diagram for the Coach application.

fans to see the most recent information at all times from the fan application. Since the roster interface Also contains the in depth list of detailed playing statistics, which are updated by the data entered in the In-game interface, these fields will remain static and locally stored until triggered to update from the online database by a clearly labeled button on the detailed statistics.

The roster interface will also feature an intuitive interface for adding new players to their team or to edit the information of players that have already been added. Clicking the “Add Player” or “Edit This Play” buttons, the user will be brought to the EditPlayerActivity, which contains simple text fields and buttons so that the user can input player data and a quick and easy fashion. Again, all changes made from this Activity will be updated globally in the online database upon being submitted locally to ensure data congruity. Additionally, the Pre-game interface will provide the user with a way to create a starting lineup for upcoming games. Since lineups are required to be submitted prior to actual games in Little league baseball, they will similarly need to be created in the Pre-Game Interface before being able to enter the In-Game Interface to actually begin recording game data.

Once clicked, the lineup creator will have a blank ListView on the left of the screen and a Scrolling View of

all of the players on the current roster on the right. Upon clicking any of the players detail buttons from the right, their detail button will be set to INVISIBLE so that they cannot be added more than once, and a ListItem will be added to the batting Lineup List on the left. This is easily accomplished by using a web of personalized detail buttons and List items all predefined in the appropriate XML files in addition to a network of ClickListeners provided by the Android API.

Once a player has been added to the batting lineup, their position can easily be changed by triggering a Dialog with the user to indicate how they would love to move them or remove them altogether. Once the batting Lineup has been complete, an Intent is sent to the FieldingLineupActivity to retain this batting order in a new Activity. The Fielding activity works similarly with the ListView on the left, which is initially populated by the empty positions that the coach must fill with his players. Upon clicking one of these

empty positions, a click Listener populates pulls all of the

players that play that position from the database and lists them in the field on the right. Once finished, the user must name the Lineup and it is stored locally in the SQLite database as well.

The in-game manager is the portion of the application that actually records in the game data in the dugout in real time. It will consist of two major interfaces, the At-Bat Interface and the Fielding Interface. Through these two screens, the user will be able to record all on field events play by and instantaneously upload them to the online database. Both interfaces will consist mainly of a network of ListViews that will be populated dynamically with all of the possible events and chains of events that can occur with the course of play. For example, when a team is in the at-bat interface, if the batter is selected, the ListView at the bottom will be populated by an internal String that contains the 7 ways for him to get on base. If any of the items in that list are clicked, the adjacent ListView will populate with more specific results of that actions. For example, if “Hit” was selected from the most basic list, the adjacent List will be filled with options such as “Single”, “Double”, “Caught out”, etc allowing more and more specific selections until the exact play is recorded, uploading it to the database and crediting all players with any stats that were affected as a result of that play. The Fielding interface is very similar, but only allows for player substitution and the crediting of defensive plays and pitching statistics.

Finally the Post-Game interface works very similar to that of the fan application, it simply pulls detailed data from throughout the database as specified by the user. The player search screen utilizes much of the same code as the roster interface, populating the ListView on the left with query results from the database and the area on the right used to display the detailed player info once clicked. Additionally, the team search screen allows the user to search for a specific team, displaying basic team information and the full roster list of that team from the online database. Finally, the Post-Game interface will allow for side by side team comparisons of basic stats from throughout the season which again, will simply be pulled from the database and displayed to the user.

C. Fan Application

The fan application allows anyone with a smart phone to view the games, teams, and players that are stored on the database. Using the phones internet capabilities the application will connect to the database through a secure connection and retrieve up to date information on current games being played, recent games that have ended, teams, and players. All of this is implemented in an easy to use

interface with large touch buttons and simple directions. The interface consists of the home page, games page, active game page, team page, player page, plays page, team and player search pages, and a speed calculator page. Here is a class diagram of the fan application.

Starting off is the games page. On this page there are two tabs. One tab shows the current games that are going on, the other shows recent games that have ended. When the page loads it sends a call to the database for both current and recent games. These are stored in string array variables in the page and the current games tab is automatically selected with the list populated by the array of current games. When the recent games tab is selected the list is populated by the array of recent games. The list is now clickable and will take the user to the active game page of the game selected.

The active games page shows something similar to a score board as well as a list that has been populated by plays that have occurred in the game. Once again, when the page loads it sends a call to the database for the games data and populates the fields with the information. From then on the page will update every couple minutes with the new information. The list of plays can be clicked which will take the user to the plays page. This page shows more detailed information about the play. The team and player search pages allow the user to enter a name into a search field to find who they are looking for. Once search is selected the app sends the name to the database and receives a list of possible matches. On the team search page the list shows the team name as well as their record. On the player search page it shows the players name as well as the name of the team they are on. These are now selectable and will take the user to the respective team or player page. The team page shows all the information about the team. This includes their name, league, coach, record, a list of games, and a list of the players. The lists are divided by tabs, when one tab is selected it shows one list. Just like the other pages, when the team page is loaded it sends a request to the database for the information on the team and then populates the page and lists. The lists are also clickable on this page.

The games list which holds the information about current or past games will take the user to the game activity page that corresponds to that game. The player’s list will take the user to the player’s page. This page also saves the last looked up team into an internal file that allows the user to come back to this user from the menu under the last team button. The player page shows all the relevant information about a single player. This includes: their full name, team name, age, position, number, height, which hand they bat with, which hand they pitch with if applicable, and all the standard stats that are recorded in baseball. When the page is loaded it sends a request to the database for the player’s information based off the name.

This data is then loaded into the respective fields and also saved in an internal file that allows the user to come back to this page via the last player button in the menu. Finally is the speed calculator page. This is accessed from the menu by clicking the speed button. This page gives several options. The two main ones are to calculate the speed of a pitch or the speed of a runner from base to base. At the top the user can select which he/she wants to measure. This populates a spinner that lets the user chose the league the game is in. This is done because the distance from home to the pitching mound or first base is different for say major league vs. minor league. At the center of the page is a baseball that says start. When the user clicks start it starts a timer that runs until the user clicks starts which is the same button. After stop is clicked the time it was run for is shown in seconds as well as the speed given by the distance selected which is shown in miles per hour.

D. Online Database

A key component to data management in this software, is managing data accesses for the devices, as well as allowing the data to be easily accessible for analysis by the teams. Among available database software tools, FileMaker Pro focuses on both of these aspects. Since the

database tools must allow two types of access, this means both types must be customized. Fortunately, they run Figure 7: A simple class diagram for the fan application

independently of each other, allowing direct template-style viewing properties while the database itself is being streamlined and modified by the device software. A coach, for example, might attempt to view the database values directly, that is, via the database software. For this type of access, a new UI within the database software must be supported, and usable by the coaches.

Based on the data organization used by baseball staticians, player stats can be split into five categories: General, Batting, Pitching, Baserunning, and Fielding. When applying these values to database fields, the database structure itself can ignore these categories. They are only required for organizing data for personal analysis and design efficiency. The fields themselves can be added, removed, or completely ignored (unused). Since the device applications will have specific functions calling each used database field, the stats stored in the database must be pre-determined. This means the coaches cannot change the stats they wish to record dynamically, unless the option to do so has been pre-programmed into the database and application. Data must be divided among specific categories, and organizing the groups is a crucial aspect to maintaining acceptable performance. To reduce complexity, each team will have their own database entry, each player will have a table entry, and each statistic will

have a field entry. 3.4 Figure 1 shows the detailed layout of the database structure. The statistical variables are stored as modifiable integer, float, and string fields, as per the requirements of each individual statistic. Since all statistics are dependant to a specific player, each player will be stored as identical tables within the team database.

General Stats Batting Stats Pitching StatsGamesStarted (GS) Singles (OneB) Base on Balls (BB)GamesBehind (GB) Doubles (TwoB) Batters Faced (BF)Games Played (G) Triples (ThreeB) Earned Runs (ER)

At Bats (AB) EarnedRunsAvg (ERA)

BattingAvg. (BA) Hits Allowed (HA)Runs (R) Innings Pitched (IP)Total Bases (TB) Home Runs Allowed

(HRA)Hits (H) Strikeouts (K3)Strikeouts (K) Run Average (RA)HomeRuns (HR) Balk(BK)

Table 1: Stored database fields

If players have statistical discrepancies, such as some players not pitching, then these unused statistical values will remain empty. Since fields and tables can be dynamically added and removed within a database, this creates an optimal scenario for the data storage, as players can be easily removed or added to any team. The fields (statistic types) will never be removed or added, since these are all based on official baseball statistic types. Each player will have all of the statistic types available to them. If an existing player becomes a pitcher, for example, the previously ‘empty’ pitching statistics are already available to be accessed. The database will need to be split into two pieces:  live data and archived data. Depending on what information is being accessed, the database will need to respond in a unique way. While a game is in progress, the database must track live data. Additionally, the database must track global data for analysis and feedback purposes. For interfacing purposes, this category will be called Team Records. This data must be updated during and after the completion of a game, to reflect the most accurate data. This kind of data is always valuable, and can be required at any time, during or after a game, and based on the needs of the data, it will always need to be the most recent values. Based on how the live data is updating, the archived data can easily increment and alter values as data changes. Also, there are events occurring during the game which may not be of value in the live data (batting/pitching averages, for example) which will need to updated in the archived data immediately.

IV. CONCLUSION

The ultimate goal of this design is to streamline the ease and accessibility of baseball statistical record-keeping, for

the coaches and umpires. Additionally, adding a new level of interactivity for the fans via the fan device application would allow spectators of little league games immediate access to new data in ways that have never been done before. This implementation allows coaches more time to focus on their team management, gives umpires the capabilities to make faster and more accurate rulings, and promotes more fan involvedness with new features.Migrating data and team management from traditional pencil and paper mechanics to a new, faster, efficient electronic system greatly improves not only user friendliness, but consequently also improves reliability and quality of the work being done.