fsTimer documentation

Section 1 Installing fsTimer
Section 2 Overview
Section 3 Checklist for timing with fsTimer
3.1 Suggestions for race setup
Section 4 Detailed descriptions of fsTimer components
Section 5 Additional details for developers

Section 3.1 - Suggestions for managing a race

The race timing software (fsTimer) is only one part of running (as in managing) a successful race. Having things organized in the right way is also extremely important. Here we describe everything that we do to organize and time a race using fsTimer, and you can take this strategy and adapt it as needed to your race.

The general process of timing the race will be: We'll go over the whole process in detail.

Bibs, barcodes, project setup

The first thing you will have to do is order race bibs. We find that the best race bibs are ones with tear-away bottoms and a hole in the tear-away part, like the one:

We use the tear-away bottoms to form our ordered record of bib IDs that crossed the finish line, by stacking them on a dowel stand (you'll have to make or buy those as well) like this:

Using a barcode scanner to enter the bib IDs into fsTimer is a great way to speed up the process and minimize errors. We have had great success even with cheap ($20) USB barcode scanners (like this one). Sometimes the bibs will come with barcode stickers already on them, otherwise it is easy to print them and attach them yourself (see fsBarcodes). Make sure that the barcode is on the tear-away bottom part of the bib, as that is the part that is collected from the racers. Of course, using barcodes and a barcode scanner is entirely optional; you can always enter the bib IDs just using the keyboard or numpad.

To create the new project in fsTimer, you will have to work with the race director to determine what age/gender divisions to use for divisional results, and what the registration fields should be. fsTimer requires name, age, and gender as registration fields, and you can add as many or as few as you'd like to those, although you won't want to be typing in large amounts of information during day-of registration.

Pre-registration and registration

Racers appreciate not having to wait in a long registration line the morning of the race, and allowing racers to pre-register helps alot. We allow racers to pre-register on our website, and then enter the information into a spreadsheet which is then imported into fsTimer before the day of the race. For those without a website, pre-registration can also be done using paper forms, and again the information is entered into fsTimer before the day of the race. Information could also be entered directly into fsTimer using the Registration window. Notice that these racers are not being assigned bib numbers when they pre-register; we are simply collecting their information so that it is in the database and does not need to be typed in the day of the race.

Pro tip: If entering data from pre-registration by hand either into a spreadsheet or directly into fsTimer, double check the age and gender. Having males incorrectly listed as females can really make a mess of divisional results.

After pre-registration is closed, you will import or enter the information into fsTimer and generate a pre-registration database which is saved into the project subdirectory (the files for a project named project_name will be saved in fstimer/project_name).

fsTimer was designed to allow multiple computers for day-of registration. If there is only one computer for day-of registrations, there will likely be a long queue which means racers will have less fun - nobody likes waiting in line! We have found that the right number of computers (and thus the right number of people helping out at the registration table) is about one per 50 racers, when registration lasts for one hour before the race. Thus, if you are expecting 300 racers at your race, you probably want to have six people day of the race with computers running fsTimer.

We have had success with sending registration volunteers directly to the fsTimer webpage (http://fstimer.org/download.htm) to download the software and install it on their own computers, which they then bring the day of the race. fsTimer is truly cross-platform and will work on most computers, although not on android or iOS.

Morning of the race, the registration computers are prepared by doing the following actions: Because the pre-registration databaes is loaded on all of the registration computers, a runner who pre-registered can walk up to any computer and their information will be there. We put a stack of bibs next to each registration computer, as the registration crew will be responsible for assigning bib numbers in fsTimer and handing out the bibs.

When a person walks up to the registration counter, the person running the registration computer will need to follow one of two sets of steps. These are the steps that you will need to train the volunteers at the registration table to do:

A pre-registered runner:
This runner's information is already in the database, but we need to give them a bib and assign the corresponding bib number to their entry in fsTimer. A runner that has not pre-registered:
We need to type in the information for this runner, assign them a bib number, and give them the corresponding bib. Pro tip: For individuals that haven't pre-registered, we have paper forms for them to register day-of, and we put these on a separate table away from the registration tables and make people fill the form out before coming to the registration table. You don't want to have people holding up the line while they stand in front of the computer filling out their registration form.

Pro tip: Name, age, gender, and bib ID are the very important fields. Errors in registration will mean errors in results, so double check these!

Pro tip: Name, age, gender, and bib ID are the only truly important fields. When people have not pre-registered, we usually skip typing in the other fields (things like address that are good to know but not critical for running the race). This helps to keep the queue short - you don't want people waiting in line while you type in information that could just as well be typed in after the race is finished!

Pro tip: Keeping the queue short the morning of the race is important for keeping things running smoothly, and making sure racers have fun. One thing that we have found makes a huge difference is to actually allow racers to check-in and pick up their bibs the night before the race. We specify a 2-hour period where we will be at the race location, and people can show up and do exactly the same things that they do day-of (pick up their bib if they pre-registered, and register and pick up their bib if not). We found that about half of racers exercised this option, thus cutting the morning-of crowd in half.

Compiling, timing, and results

Close registration 15 minutes before the race is to begin. Note that in order to be reasonable doing this, it is important to not have a long queue of people still waiting to register - See the above tips on how to keep the line short. If people show up after registration has closed and want to run, it actually isn't a big issue. You can give them a bib and they will still show up in the overall results, just not in the divisional results (because fsTimer won't know their name/age/gender).

Use a USB flash drive to collect the registration databases from each of the computers used in registration. The database file will be in the project subdirectory, and will have in the filename the registration number that you assigned to that computer. (You can see on the bottom of the registration window what the filename is every time you hit "Save"). Put all of the registration databases onto the computer that you will use for timing at the finish line, and compile them. When compiling, fsTimer will check that no IDs are overloaded (meaning, one bib ID was assigned to multiple people). This can and does happen due to entry error - have the registration volunteers triple check bib ID when they enter it in and hand out the bib! If fsTimer finds this type of error, it will tell you, but you generally won't have time to try and find out who actually has that bib number, and so fsTimer will autocorrect the error for you in the only reasonable way (see Section 4.4 for details on the autocorrect).

The end result of compilation is the timing dictionary, which is what basically a big table that matches bib IDs to name, age, and gender. Take the computer out to the finish line, enter the Timing module, load the timing dictionary you just created, choose a pass ID (usually 0, the number zero) and enter the timing window.

Note: The tips about operating the finish line below are for races with only one lap, where the racers have a bib bottom that can be torn off. Races with multiple laps will not allow for the bib bottom to be torn off at each lap, and so these tips won't apply. see Section 4.6 gives a description of how lap timing works.

We will now discuss how to organize the finish line crew. The key to successful timing with fsTimer is to make sure that all of the times are marked, and all of the bib IDs are recorded in the order that they crossed. For races with 50 or fewer runners, this is not too difficult - it is easy to have one person marking times on the computer, and one or two others manually (as in, writing down on a pad of paper) listing the bib IDs in the order that they cross. With more than 50 runners, a more complex strategy will be important to be able to handle the load. We have done 5k races with 500 runners, and from around 25 minutes to around 35 minutes it is a solid stream of runners, and one could not possibly write all of the bib numbers down manually. We have found the following finish line setup to work with 500 runners on a 5k - you could make adjustments and scale it as you think necessary for your race.

From the finish line, we form a "funnel" out of cones and caution tape that forces down into a single-file line. The chute needs to be long enough for the fast runners to slow down enough by the end of the chute for their bib bottom to be torn off. It also needs to be long enough that if things start to get a little backed up due to runners coming in faster than their bib tags can be torn off, the queue doesn't spill back over the finish line. We find that about 40 feet is the right chute length. It will seem long, but if you have fast runners or a large number of runners, you'll be glad you did it. The chute is indicated with dashed lines in the illustration above. At the finish line, there is a table on which the timing computer is put.

We now describe the roles of each of the finish line crew. Keep in mind the general philosophy of timing with fsTimer: keep track of crossing times, separately keep track of bib IDs that cross, and then fsTimer will line those two stacks up. We'll first describe the procedure for "normal" operations, and then will get into the complications that will arise and how the finish line crew need to be ready for them.

Crew 1: Crew 1 is responsible for marking times. They will be on the phone with the person starting the race, and will press the "Start!" button at the same time as the race begins. Whenever a racer crosses the finish line, they will press spacebar to mark the time.

Crew 5: Crew 5 is responsible for tearing off the bib bottoms and handing them to Crew 4. Their focus is to be sure that every person that for every person that crossed the finish line, a bib bottom is handed to Crew 4 so that the bib ID record stays synchronized with the marked times.

Crew 4: Crew 4 holds the dowel stand, takes the bib bottoms from Crew 5 and places them, face down, on the dowel stand, just like in the picture above. The stack of bibs on the dowel stand forms a record of who crossed.

Crew 7: For larges races, things will get busy in the middle and there will be clumps of people that come faster than Crew 5 can rip off the bib bottoms, and a line will start to form inside the chute. Crew 7 has two important jobs: The first job is to make sure that nobody cuts out of the chute (this person already had their time marked, and we must collect a bib bottom from them or things will get out of sync). The second job is to actually go through the line of people in the chute and help them rip off their bib bottoms, and have the runners holding their own bib bottoms. That way when they reach the end of the chute (the front of the line), they just have to hand their bib bottom to Crew 5 and the line can move faster.

Pro tip: It is extremely important that all bib bottoms go through Crew 5, so that they stay in the right order. Crew 7 should help runners tear their bottoms, but should not collect them, because Crew 4 would not be able to merge stacks of bib bottoms from both Crew 5 and Crew 4 in the correct order.

Crews 2 and 3: It takes some time to enter in all of the bib IDs, and so to get results as quickly as possible after the race this is best done while the race progresses. While the race is going, Crew 2 will be responsible for entering the bib IDs into fsTimer, on the timing computer. They will do this using either a barcode scanner if the bib bottoms have barcodes (highly recommended), or using a usb keyboard or numpad that is plugged into the timing computer. Crew 3 is responsible for bringing the bib bottoms from Crew 4 (who is forming the stack) to Crew 2. With a chute length of 40 feet, this means that Crew 2 will be doing a lot of running back and forth.

We use a collection of 4 dowel stands for transferring bib bottoms from the end of the chute, where they are torn off, to Crew 2 where they are entered into fsTimer. We call them the "collection," "transfer," "scanning," and "entered" dowels. Alternative: This process is a little complex, and is not strictly necessary as entering IDs is entirely asynchronous from marking times. So, there is not necessarily any hurry to enter in the IDs. An easier alternative is simply to have Crew 4 collect all of the bib IDs on one dowel stand, and then when the race is finished have Crew 1 enter all of the IDs in one go. We just prefer to enter bib IDs as the race progresses to have results as quickly as possible.

Alternative: It is also possible to record times on one computer, and have Crew 2 using a separate computer to record IDs. These two lists (the list of times and the list of IDs) can then be combined using the "Merge" feature that is discussed in Section 4.5.

Pro tip:One might be tempted to try to actually use the barcode scanner at the finish line to directly scan people's bibs as they exit the chute. This saves the whole process of tearing and tracking bib bottoms. While this is great when it works, we have found that this is in general a very bad idea because if something happens (for example, if the barcodes get faded from rubbing against people's jackets and the scanner has a hard time reading them, or if a small child trips on the USB cable and unplugs the scanner - both of these things happened) then no one can be checked in, a queue will quickly spill back over the finish line, and times will be lost. Even in small races, your timing strategy should never rely on being able to enter IDs into fsTimer as fast as runners arrive. Having Crew 4 means that no matter what happens we have a record of who crossed and in what order. For large races (300-500), at the peak runners will be arriving faster than Crew 2 can enter their IDs into fsTimer, even with a barcode scanner.

Pro tip:Another tempting strategy would be to use a USB extension cable to move Crew 2 next to Crew 4, so that Crew 3 doesn't have to run back and forth the whole race. We have found that this is also a bad idea as long cables can easily come loose or disconnected (e.g., by being tripped on by small children), and the IDs might not be getting scanned in.

Crew 3: Crew 3 can also have a side-duty of ensuring that runners are not cutting out of the chute on that side. If racers leave the chute, then their time has been marked but no bib will be collected and so those two stacks will get out of sync.

That is the workflow for "normal" operations: Crew 1 marks times, Crew 5 tears bib bottoms, Crew 4 collects bib bottoms, Crew 3 takes bib bottoms from Crew 4 to Crew 2, and Crew 2 enters the bib IDs into fsTimer. There are, however, a number of complications that can arise, and Crew 5, 6, and 8 will be responsible for handling these complications and ensuring there are no errors.

Crew 8: In races of 300+ people, there is a reasonably large chance that the stack of IDs and times will get out of sync. There are a number of reasons why this can happen - maybe a runner crossed the finish line but left the chute. Maybe Crew 1 marked a time for a child with no bib that Crew 5 didn't notice. Regardless, Crew 8's role is to collect the necessary data to allow us to correct any of these errors after the race is completed. Specifically, Crew 8 will take a manual record of a sampling of the finish times using a stopwatch that was started at the same time as the race clock and this form. This will not be a complete record, but rather Crew 8 will note the bib ID and finish time for one racer about every 20 seconds. When the race is finished and all of the bib IDs have been entered, we can then look through the results on the timing window and find each of the marked IDs and check that their times correspond to those noted by Crew 8. If we see that a time is incorrect, then we will also see that there is an extra ID or time that was marked and will be able to drop the extra using the editing tools described in Section 4.5. If Crew 8 tracks one completed racer every 20 seconds, then even if times and IDs get out of sync we will be able to correct them and we can guarantee no errors of more than 20 seconds in the times.

Crew 8 can also ensure that nobody crosses the finish line, and then attempts to back out and go around the chute. Of course, if someone doesn't cross the finish line and wants to run outside the chute, that is OK; it's only a problem if Crew 1 marked the time for them, which will generally happen when they crossed the finish line.

Crew 5: Crew 5's role is to rip off bib bottoms, and ensure that for every person that crossed the finish line, a bib bottom is handed to Crew 4 so that Crew 4's record will be synchronized to the marked times. Unfortunately, probably about 10 times per 100 racers there will be situations where Crew 5 will not be able to tear off a bib bottom, or will not want to. Some of these situations (the common ones that we have seen repeatedly) are: For all of these situations (and any other new situation that might arise where a bib bottom is either unavailable, not quickly available, or in bad shape and might fall off of the dowel), Crew 5 will use what we call a "blank." A blank is a piece of heavy stock paper (or something better if you think there might be rain) that is approximately the same size as the bib bottom, and has the "pass" ID barcode on it.

The most important thing for Crew 5 to keep in mind is (again) that for every person that crosses the finish line, something needs to be handed to Crew 4 - either the runner's bib bottom, or, if it isn't available, a blank. The blanks thus keep the bib IDs synchronized with the marked times, regardless of complicated situations that may arise. Crew 2 will then scan the blanks (thus entering the "pass" ID) just the same as if they were a proper bib bottom.

Crew 6: Crew 6 is then what we refer to as the "error-corrector." Anytime Crew 5 uses a blank, the runner for whom the blank was used will be given to Crew 6 who will then make a record that will be used to retroactively fill in the correct bib ID in the place of the "pass" ID. Crew 6 will have a clipboard and a sheet of paper in which to write the true bib IDs of the runners for which blanks were used. He/she will also write the bib number of the runner that followed the "blank"-ed runner, so that the appropriate blank in the results can be found and filled. You can download our sheet here:

We strongly recommend gathering the finish line crew together the week before the race, going over each of their roles, describing the types of complications that can arise (like those listed above), and actually simulating the whole finish line process (together with some complications). If everyone knows what to do, then things will go smoothly and you will have accurate times.

When the race is finished (the last bib ID has been entered into fsTimer), you must use the error tracking sheet from Crew 6 to retroactively correct any blank times with the correct bib ID. You must then use the sheet of known-good values from Crew 8 to correct any sync issues that may have occurred. This should not take more than a few minutes, and then the times are ready to be printed and posted.

Pro tip: Any time you press "Print" in the timing window, the "as-of-now" formatted results are saved to html files that can be printed. When possible, it's great to post "as-of-now" results at around the 70% mark of the race so that the fastest runners don't have to wait quite so long to see what their results are. Be sure to emphasize that these are preliminary results, especially as the people from Crew 6's list will not be entered until the end of the race. Of course, printing results mid-race requires using a USB flash drive to copy the html files off of the race timing computer, to be taken to another computer for printing. This works great for smaller races, but for larger races there might not be any pauses in the flow of runners long enough to copy the files to the USB drive (notice that Crews 1 and 2 will have to pause their work for the duration of time required to get the files onto the USB drive).

Continue on to Section 4 Detailed descriptions of fsTimer components.