Skip to main content

Recording in the field

As part of the work we have been doing for the Surrey League, we have come up with a couple of useful prototype apps so that finish times and positions can be recorded quickly using commonly owned handheld devices. Compared to the traditional method of pen and paper, the advantage is the data entered in this manner it can be analysed instantly without the need for retyping. (A user manual is here, and for the real geeks, the spreadsheet with the data is here).

As with all prototypes testing is key. The number entry system was tested for the ladies surrey league in a purely observational capacity and used for the actual results for the men’s surrey league later the same day. Testers for the ladies were A and E Weir and for the men’s A Weir and A Bickerstaff.

The first lesson is to test the system properly we need to work with the organisers. At the ladies race we were just a test on the side and had to”promise not to get in the way”. At the men’s fixture where we worked with Ranelagh things went a lot more smoothly.

The system operators worked in pairs; with a caller who called out the numbers on the vests and the other typed. The max speed of data entry is marginally slower than writing, some of this difference could be reduced if the audible feedback of a key-stroke was optimised or perhaps the area of the screen allocated to the keyboard were increased. Fat fingers need fat keys! The big lesson however was you need your own number caller, relying on another caller who is serving a (pen and paper) writer, means you have no control to ask for a repeat or to slow down. On the keypad design, it would be nice to move the <enter> key away from the change window button on the iPhone! A mis-hit has dramatic effects.

Analysis of the data “as typed in” showed that the median time between runners being entered (3 digit numbers) was just under 3 seconds, with 75% being under 3.5 seconds (all data is in attached spreadsheet). So it is a fair assumption that we can deal with 20 runners a minute. Interestingly, when there is an error we jump to a tail event (5 seconds) - accuracy is key. With improved app design we should be able to get a 20% speed up so 24 runners per minute.

If the number of runners builds up that is fine as long as we can store them somewhere and process them in order. Runners can, probably, stand being in a queue for 1-2 minutes before they get restless so a back up of more than 24 to 48 runners is problematic. Also sweaty runners tend not to stand too close to each other, so assume 1m+ of funnel per runner.

With a long funnel, the system can currently just deal with a men’s surrey league. (That is multiple minutes of 30 runners a minute). Practise clearly helps here, as the system failed to deal with a similar flow rate for the juniors, however as the operator and caller team learnt the system so the speed and accuracy picked up. (Men’s flow rates are in spreadsheet).

It is interesting to analyse the Women’s flow rates to see the limit of the written system (also is spreadsheet). There were 9 continuous high volume minutes (here defined as >20 runners a minute) with peak flows at 45 runners a minute for a couple of minutes, at this volume even writing fails and the multiple funnel system is required. This shows the system currently is not far off current optimal, and should be able to deal with complicated races (with some minor modifications, and perhaps younger and more dextrous typists) up to the limit of the current written system. In the sheet you can see the massive effect a pick up in speed has on queue length. If we were to use our historical speed on a single funnel, we would have a maximum of 150 runners in the queue (or a 7.5 minute wait time and a queue length of about 5% of the distance actually raced). Even 24 per minute results in too long a queue. If we could get to 35/min then the queue stays below 20 runners.

Any ideas how to speed it up? Perhaps voice recorders for the more frantic moments (and accept limited retyping)?

Footnote: Going forward we must make sure the system does not get blamed when actually the volume would be too high for any system.

It is worth noting the UKA guide to cross country has the following (very conservative) guidelines:

  • 100 runners require 1 funnel
  • 200 runners require 3 funnels
  • 300 4
  • 400 - 600 5
  • 700 - 900 6

Want to give Opentrack a go?