Mick Bromilow has been heavily involved with producing results for road races, track and field, cross-country and endurance relays over the last fifty years. He is also a Level 2 timekeeper.
As an academic at the Open University for forty years, his expertise is in numerical analysis, the study of methods for solving mathematical problems using a computer. Mick shares his process and advice to assist race organisers in producing quick, accurate results for endurance races.
I produce results for the Chiltern Cross Country League. For cross country leagues the order of the finishers is more important than the individual times, as team positions depend on the correct ordering.
Finding a solution
Several years ago, we hired a local chip-timing company to produce the results for the 10 races in each fixture, in the expectation it would produce accurate results quickly. We used a portal system for team managers to enter their athletes (and, once entered, they remained on the database until the team managers deleted them). After three years of working together, we parted amicably – we still use their portal system, and they still print the bib numbers for the league.
Unfortunately, I was finding that I was still spending as much time sorting out problems with the results as I was when we did everything manually, and they were not making any money. I wanted to find a better system for collecting the data and processing the results.
Sources of error
The main sources of error for manual systems are: missing data, mis-recording data, mis-interpreting data and mistyping data. There are other sources of errors: runners wearing the wrong number, team managers not declaring the runner, family members wearing each other’s numbers and so on, but these are difficult to eliminate in any system!
For chip-timing, there are three main sources of error.
- The first is the two-mat system, where most transponders transmit to the first mat and a small number the second mat 2-3 seconds later.
- The second is chips on ankles rather than the chest can cause an incorrect ordering.
- Finally, the fact that transponders transmit to the mat as it gets close to it in a not necessarily consistent way. Other problems arise if team managers (with numbers in their bags) or non-competing runners get too close to the mat at the finish.
I started looking for a system of data collection that would eliminate as many of these sources of error as possible. What I came up with was a solution like that used for parkruns. I found a stopwatch on Amazon (search for JUNSD) that would record up to 500 times from multiple races, and these times could be uploaded into a laptop. I also experimented with using scanners to record barcodes prominently displayed on the runners' numbers.
The scanners work best when the trigger is lightly pressed rather than held down.
System set up
After five (pandemic interrupted) seasons we have the following system.
- Two timekeepers alternating races, with two multi-time stopwatches on each race (in case of problems) and with both timekeepers recording the senior men’s race.
- Two scanners recording numbers, initially alternating races, but recording the runners in separate funnels when more than one funnel is being used.
- Manual backup on recording the numbers.
We use slightly longer funnels than normal so that the scanners can work their way up and down when the funnels are busy. In road races, we’ve found that the best people to do the scanning are often those with parkrun experience.
Scan results improved when I discovered that the volume of the beep could be amplified.
At an event
Over the last season of five Chiltern League Meetings, including a UK Cross Challenge/Home Countries International event, we have had precisely the right number of times for all 51 races. Using the watches requires the skill of the timekeeper in avoiding anticipating the finish, but clicking the watch as each runner crosses the line is much easier and more accurate than manual recording. Occasionally, if four or five runners cross the line together you need to click the watch quickly 4-5 times, but a good timekeeper can do this in about one second.
In the same five meetings the scanners have missed a handful (significantly less than 10) of numbers in each meeting. These have been added later using the manual back-up, which is also used to sort the stream of numbers from each of the scanners into each race.
Uploading the times and numbers when I get back from a meeting (or in real time for the last meeting) means I can generate results very accurately and very quickly. Team managers have a deadline of a couple of hours after the end of the meeting to finalise their declarations. There’s usually a small number of athletes not declared, but an email to the offending team managers allows us to give final results early on the Sunday morning. I no longer need to answer emails from runners who don’t appear in the results, but ran, or from runners who did not run, but who appear in the results.
With any new system there are sceptics, but the ever increasing cost of putting on events is forcing organisers to look for more cost-effective solutions. I know other cross-country leagues are now using very similar systems: the use of team portals, scanners and multi-time stopwatches is beginning to be much more widely used. We have also started using the same system in the East Midlands Grand Prix Road Race Series, where I also produce the results.
This is not a system for large-scale events where runners take time to cross the start line, or the density of finishers is too high, but for smaller cross-country meetings (where positions matter much more than times) and small-scale road races they are cheap and accurate. We even used the system successfully in last September’s Aldershot Relays.
Photos from the Chiltern Cross Country League by Gary Mitchell