fsTimer documentation

Section 1 Installing fsTimer
Section 2 Overview
Section 3 Suggestions for race setup
Section 4 Detailed descriptions of fsTimer components
4.1 Setting up for a new race
4.2 Importing preregistration - details
4.3 Registration - details
4.4 Compiling registrations - details
4.5 Race timing - details
4.6 Timing multiple laps
4.7 Handicap races
Section 5 Additional details for developers

Section 4.4 - Compiling registrations - details

When registration is done on multiple computers, each one will have saved on it (in the project directory) a registration database. For a project named project_name and 2 computers that were given registration IDs 1 and 4, you will create the merged database by compiling the files project_name_registration_1.json and project_name_registration_4.json.

All of these files are put on one computer (we use a USB flash stick), and are then merged using the "Compile" module in fsTimer. The "Add" button is used to select the files that are to be merged:

The "Remove" button removes a selected filename from the list. When all of the registration databases to be compiled are on the list, then press "Compile". The "Compile" operation will create two new files: A merged registration, that will be saved as project_name_registration_compiled.json; and a timing dictionary, that will be saved as project_name_timing_dict.json. The merged registration is a normal fsTimer registration database file that could be opened, for instance, in the Registration window. It contains all of the entries from all of the compiled databases. The timing dictionary is a dictionary that allows fsTimer to look up runner information (registration fields) by bib ID. When a runner's bib ID is entered into the Timing module of fsTimer, it will use the the timing dictionary to look up what the corresponding registration information is. Under normal operation, pressing Compile will work nicely, the registration databases will be combined and the files written.

In some instances, fsTimer will find a particular type of error in the registration databases. The particular error that it checks for are overloaded IDs. This means that the same ID was (in the registration databases) assigned to multiple runners. For instance, ID "110" might have been assigned to "John Smith" in project_name_registration_1.json, and assigned to "John Doe" in project_name_registration_4.json. This is an issue when forming the timing dictionary, because now when fsTimer wants to look up the information for bib ID 110, it doesn't know if it should use John Smith or John Doe. If fsTimer finds overloaded IDs, it will raise an error and tell you:

Notice that on the Compile window it now says "Errors found!" in red on the bottom, and a new window has popped up with a list of the overloaded IDs. In the above screenshot, IDs 103 and 110 were overloaded, meaning that they were assigned to multiple entries. We should briefly note that this means unique entries - if the same ID is used in multiple registration database files along with the same other information (Name, age,... all of the registration fields), then this is not a problem.

The most likely source of overloaded IDs is entry error by the people running the registration computers. If you click on an ID and press "View ID entries", it will bring up another window that will list for you the conflicting registration entries:

In the image above, we see that Gene Gomez and Tiffany Parker were both assigned bib ID 103. When this happens, there are two ways to proceed. If you know which of the entries is the actual runner with bib 103, then you can select that entry and press "Keep entry". For example, selecting Gene Gomez and clicking "Keep entry" will mean that in the merged database (and the timing dictionary), Willie will have the ID 103, and Tiffany will be left with a blank ID field. In a real race scenario, the time interval between closing registration and starting the race is usually pretty short (we close registration 15 minutes before the race starts), and so there simply is not time to figure out which is the correct entry. In this situation, just press "OK" and then press "OK" in the overloaded IDs window.

When you press "OK" in overloaded IDs window, it leaves all overloaded IDs unassigned. This is the right thing to do, unless you actually know which are the correct entries. When the runners cross the finish line, they will still show up in the results, but they will just show up by bib number alone, and without their registration info (name, etc.). Unfortunately this means that they will not show up in the divisional results, but this is something that you can correct after the race when you have time to actually figure out what the correct entries are.

Once all of the overloaded IDs are corrected, compilation will continue:

The Compile window says at the bottom "errors corrected" and will print the names of the compiled registration database file and the timing dictionary file.

In addition to the timing dictionary and the compiled registration database in fsTimer format, fsTimer will also save a csv spreadhseet containing the merged registration information to the file project_name_registration.csv. This is useful for having a portable spreadsheet with all of the registration information collected day-of.

As mentioned at the bottom of the screenshot above, the compilation process also generates start sheets. These are nicely formatted printouts that list all of the registered racers ordered by ID. There are two startsheets generated, both stored as HTML files in the project directory: one file with all registered racers in one list, and a second file that has the registered racers broken down by division:

As a final note, as was mentioned in Section 2.4, even if there is only one registration database to be used for timing (i.e., there is nothing to merge), you must still compile that one registration database so as to create the timing dictionary.

Continue on to Race timing - details.