Proceedings of the Winter KGCOE Multi-Disciplinary Engineering Design Conferencepage 1

Proceedings of the Winter KGCOE Multi-Disciplinary Engineering Design ConferencePage 1

Project Number: 05511

Copyright © 2005 by Rochester Institute of Technology

Proceedings of the Winter KGCOE Multi-Disciplinary Engineering Design ConferencePage 1

STONEHURST REGATTA RACE TIMING SYSTEM

Douglas A. Carr / Mechanical Engineering / Robert Magnant / Electrical Engineering
Jeffrey Lisco / Electrical Engineering / Juan Gonzales / Electrical Engineering / Jacob Johnson / Computer Engineering

Copyright © 2005 by Rochester Institute of Technology

Proceedings of the Winter KGCOE Multi-Disciplinary Engineering Design ConferencePage 1

Abstract

This papers summarizes the efforts of Senior Design Team 05-5511 to develop a system capable of eliminating race timing errors that were occurring at the Stonehurst Regatta crew race in Rochester, NY. The team has developed a system to electronically collect, organize and transmit boat numbers and corresponding race times from the collection points at the start and finish lines to the final processing location at the “results booth.” The paper documents design considerations as well as the final implementation

introduction

The Stonehurst Capital Invitational Regatta is an annual fall crew race occurring on the Genesee River in Rochester, NY. Teams of boats from around the northeast United States and Canada gather at this unique race in the rowing world to compete in two separate events throughout the day, a long, endurance style “head race” in the morning and a shorter, more exciting head-to-head style “sprint race” in the afternoon. Times from each event are combined and awards are given based on the overall performance for the day.

In the past results collection has been performed using a printing stopwatch from Seiko® for start and finish line times, and a pen and paper for corresponding boat numbers. This method worked extremely well for collecting data, but results were then transmitted to the results booth at the boat launch site by verbally reading via a cell phone to a person entering data on a laptop. Since the volunteers performing this task are under pressure to publish these results quickly (so that trophies can be awarded in a timely fashion,) mistakes have occurred during the transcription process, which were not caught until after the awards had been given out. This has led to the post-race retraction of some awards, which is both frustrating for the competitors and embarrassing for the race officials.

The objective of this RIT Senior Design project was to create and implement a system or method for alleviating the problems occurring during data transcription. The project sponsor desired that the solution be user friendly and robust, since the race volunteers come from varied, often non-technical backgrounds, and also that it integrate easily into the current system without impairing the current functionality, so that a backup system is readily available. The team was given $500 to design and build a fully functioning system to be implemented in the next race in October, 2005.

Nomenclature

GUI – Graphical User Interface

RFID – Radio Frequency Identification

RS232 – Serial data communication standard

RTC – Real Time Clock

Project Requirements

Several key parameters define the design requirements of this project. The system must fix the problem, be simple to use, reliable and robust enough to survive in a wide variety of usage environments. These objectives must also be completed on time and within budget. A more detailed look at each of these parameters follows:

Addresses data entry problems:

The major function of the prototype will be to remove the process of manual data entry (i.e. keying in results being read over the phone) while transcribing the data from collection points (i.e. the start and finish lines), to the results booth. According to the project sponsor, in the past this step has been the most subject to human error, while other aspects of the current method have proven themselves rather reliable.

Ease of use:

A major point of emphasis is that the final product should be simple to operate and generally easy to use. The people that run the timers during the race are typically volunteers from the Rochester community who are trained at the race site, on the day of the race, and often have little or no technical background. Even technically savvy and experienced timing personnel only participate in the system once a year, so any user interface should be intuitive and uncomplicated.

The design should display the results quickly so that users can visually verify the data, and they should also have the ability to delete accidentally recorded results. The design should have visual user feedback (e.g. an “On” light) so that it can quickly be verified that the system is properly functioning. Any third party software should be common and familiar, and any Graphical User Interface (GUI) should have familiar feeling functionality to the average computer user.

Reliability:

The design should take as much user error out of the picture as possible. The final design must be reliable, as this competition is a large, chaotic event with several hundred teams competing and many thousands of people watching. Initially the new system will be implemented with the intention that the current stopwatch and cell phone system will be readily available should anything unexpected happen. If the design proves reliable, then it will become the primary system; however, the design should allow for reversion to the old method in any case.

Accuracy:

Discussion with the project sponsor revealed that the results are currently recorded and published to an accuracy of 0.1 seconds. These results are accepted as accurate, including any inconsistencies due to human involvement in collecting results. 0.1 seconds is a standard in the collegiate regatta world that is generally accepted and has been achieved in past years through the use of printing stopwatches, which record times to .01 seconds. Any delay caused by our system should not jeopardize the 0.1-second accuracy of the results.

Also to be considered in this category is the fact that multiple boats will be crossing the lines in close proximity to one another. Though the starting line in closely controlled, throughout the course of the race boats can overtake one another, which means that several boats could reach the finish at nearly the same time. The finish line is approximately 100-ft (30.5-m) wide, and boats with oars fully extended can be 20-30 feet wide, so the system needs to be able to record as many as three results in extremely rapid succession while maintaining the 0.1 second accuracy.

The project sponsor also stipulated that the results recorded by the system should be confirmable, such that they can be checked for accuracy at a later time. This can be achieved if the printing stopwatches continue to function in parallel with the design, since they create a hard copy of the data which can then be used to verify the electronic records.

Survivability:

The Stonehurst Regatta takes place in October on the Genesee River, so weather is a serious concern in any design. We have set design goals in this regard to attempt to encompass all possible conditions. The design should be able to function properly in temperatures from -10 to 40 degrees Celsius (15-100 F.) It should also be able to function in wind, rain, snow, bright sun, humidity or any other weather conditions common to Rochester, NY.

Durability:

The system should be physically strong and durable. It will be carried around by hand and used outside so an impact from a drop or bump will not be uncommon. This means that any materials selected should be strong but also impact resistant, as well as water resistant and thermally stable.

Budget:

The budget for this project is $500, which places constraints on how much can be done. For instance, it would not be possible to create a system that would identify the boats and take the times automatically without any human involvement, which was one of our initial design ideas.

Integration:

It is desirable that the system that we design integrates seamlessly into the current system, so that the printing stopwatches can continue to be used as a backup. The project should take simplicity of integration into account so that should any future improvements to the system be desired, they could be performed easily.

initial design

The initial concept was developed without direct knowledge of the project budget, and was considered to be an optimal design. The concept was an attempt to completely eliminate human interaction in the data collection by implementing an automated method of identifying each boat and recording each boat’s time via Radio Frequency Identification (RFID) technology. RFID technology is in fairly common use, and generally consists of a passive transponder, which is be powered and subsequently activated by passing through an electromagnetic field. Once activated the tag emits a unique radio signal that can be detected by a nearby antennae. Common applications include anit theft devices in retail stores, vehicle identification in automated highway toll booths, and very similar application for tracking large marathon results that involves attaching a small tag to the shoe of each runner.

Figure 1 - Bow Ball

The design called for securing one of these RFID tags to the tip of the bow of each individual boat by embedding it in a plastic device that would fit over the boat’s “bow ball.” (Figure 1) An emitter antenna would be either draped over the top of the start/finish line or secured beneath the water, and would trigger the tags as the boats crossed the line. A nearby receiver antenna would then detect the output signal from the tag and activate a stopwatch device what would electronically store the time in a data buffer. Times would then transmitted automatically by a wireless method to the results office where they would be stored on a program on a laptop computer.

Figure 2 - Initial Design Process Flow

While this completely automated design would have been an optimal solution, our order of magnitude cost estimate for the design exceeded $2000, due to high part volume (1 tag per boat over 100 or more boats) and expensive antennae technology. Though one of our options according to the project definition at the time was to build and test a simplified prototype and not a fully functional system, the team’s personal goals included fixing the problem in a timely a manner.

Once the details of our budget were ascertained, it became clear that we would not be able to construct a completely functional system for the race in 2005, nor did it seem likely that the funds could be easily secured to complete the system at a later date. Based on this reasoning, the design was deemed not feasible and thus a simpler design was developed with a narrower scope.

Final Design

Given the cost constraint, it was determined that the most feasible plan for creating a reliable system would be to find a way to integrate into the current system in such a way that the results from the current would be captured electronically. This means that the device needs to interface with the Seiko® S129 printing stopwatches, which are currently used to record results, both to trigger the stopwatch to print, and record a time electronically in parallel. The concept that has been developed around this framework is to build a centralized platform that would integrate the following devices and features together into a cohesive system.

Stopwatch:

The current system uses a Seiko® S129 stopwatch (Figure 3) to record each boat’s time. It is desirable to keep this current system functioning because of its reliability. The stopwatch system has proven its ability to capture the race time accurately, with only one boat in many years not having its time properly recorded by a volunteer with a stopwatch. The team’s first idea was to attempt to utilize the “data output jack” found on the bottom of the stopwatches to obtain the race results. This proved to be impractical upon further research because the six-pin connector is an extremely non-standard design, which also happens to be Seiko proprietary and not readily available or easy to imitate. The Seiko cable needed to access this jack has never been sold on the U.S. market, and the stopwatches do not appear to be compatible with any standard software or data standards such as RS-232.

Figure 3 - S129 Printing Stopwatch

A second possibility was to utilize the stopwatch’s remote triggering capability to activate each start/stop and capture the time using a separate device triggered in parallel, since receiving the time data from the stopwatch is not an option. The remote trigger works through another simpler connector, also found on the bottom of the stopwatch. When a button is pressed on a pistol-grip type handle, the two pins in the connector are shorted together, which has the same effect as hitting the stopwatch button to record a time.

Real-Time Clock:

The project requires that there be a universal time so that each boat will receive a time from the same clock. It was decided that a Real Time Clock (RTC) module could provide the project with the necessary universal time and accuracy to record each race result. Each RTC would be synchronized before the start of the race, both between units (i.e. start and finish line devices) and with the stopwatch, so that all timekeeping devices will display the same time throughout the course of the day. This can be easily accomplished using a built in reset feature on the RTC and by taking advantage of the fact that the stopwatch start can be triggered simply by mimicking the signal created by an event (i.e. triggering the device via the connector in the bottom.) When a boat crosses a start or finish line, the time from the RTC can be recorded and since the times at the start and finish line are synchronized, a simple subtraction of times from the start clock and finish clock is all that is required to obtain the total course time.

PIC Micro Controller:

In order to handle signals between the trigger, stopwatch, RTC, memory storage, and communication to a laptop a PIC micro controller will be used. The PIC will receive a signal equivalent to the command “get a time” from the operator when a boat crosses the start or finish line. It will then proceed to interface with the RTC and retrieve a time, then send that information to the data handling program.

RS232 Communication Chip

Once the data is retrieved from the RTC it will need to be exported out of the unit to a program running on a laptop computer. RS232 serial data communication standard is mature, well developed method for doing this, and prefabricated microchips are available at low cost which communicate across nine-pin RS232 ports in a standard fashion. The PIC controller will activate the RS232 chip and communicate the data to it for transfer.

Data Collection Program

The system will be connected via 9-pin RS232 ports to a nearby laptop, which will have a data collection program running to handle the times. The data will be displayed in the order in which it is received, and a parallel list of corresponding boat numbers will also be displayed. These numbers will also need to be inputted directly by the person operating the program.

Keypad:

To keep track of boat numbers, the existing system involves having another volunteer writing down boat numbers using a pen and paper as boats cross the finish line. Though this method works well in the current system, in order to make the data from the RTC meaningful, the finishing order will be included in parallel with each result. Boat number data will be entered through a custom GUI in our data collection program, and will displayed in parallel to the corresponding boat times.

Wireless Data Transfer:

The laptops connected to each unit will be wirelessly connected to the internet using commonly available technology such as PCI Modem over cellular network. When the operator indicates that it is time to send results, the program will automatically connect to a website and upload a formatted results file with times and corresponding boat numbers to a remote web page. These results will then be openly available for download by another person or program in the results booth were they can be handles electronically (i.e. cut and pasted) into the current data handling program, which performs the necessary math and allows for input of other information such as faults.

Visual Confirmation (LED’s):

One of the requirements is to have visual confirmation that the system is functioning correctly. Three LED’s will be employed in the design: one to indicate when the power is on, one to flash when the trigger is activated and a time is captured, and one to indicate that the system has been synchronized.