The most convenient way to start a race is by hand, at the push of a button. But that is also the least accurate method. There are, however, ways and settings that can improve the accuracy of a hand start, and that is what this blog post is about. (Note that you need SprintTimer v. 15.1 for this).
There are two problems with starting by hand: The human reaction time and the inconsistency. But the reaction time can to some extent be compensated for and the inconsistency can be minimized with good practices. SprintTimer has two settings that can be used for compensation when using a hand start: The offset time and the sound distance. In both cases, the set time is added to the total time of the race.
The offset time was originally intended to allow a delayed start, but it can also be used to compensate for the reaction time. Say your reaction time is 0.15 s, then just enter 0.15 in the offset field and your times will be more accurate. But how do I know my reaction time, especially since it involves pushing or releasing a button on an iPhone? Well, here the Hand /Mic setting in SprintTimer comes in handy.
Using Hand/Mic to measure reaction time
You will need something that plays a start sound (e. g. the test animation below) or a second person who makes the sound.
– Set the start to Hand/Mic in the start set up.
– Play the start sound and press/release the start button as quickly as possible
– Start and stop the recording (you don’t need the recording)
– Scroll the graph to the beginning of start sound and note the offset time
– Repeat a couple of times and calculate an average
– Add that time as the Offset time in the start set up
Using the sound distance
When using traditional stopwatches timekeepers are trained to start on the flash or the smoke from the gun, to avoid the delay caused by the sound traveling from the start. With SprintTimer you can use the sound as well, just enter the distance to the starter in the sound distance field in the start setup. You should use the strongest and clearest signal available, sound or light. If the signal is weak (small flash, low sound) it will add to the delay and the inconsistency. Your brain will spend some additional time wondering if it is really seeing what it is supposed to see, and that time will vary from start to start. Your reaction time might also be different. So if the visual feedback is weak, use the sound.
Test animation
To test different start modes you can use a test animation I have made. You can also use it for the hand/mic sound calibration mentioned above. The animation shows a flash and plays a sound after 2 s and 10 s later an animated square will pass the finish line. Run the animation on a computer and SprintTimer on an iPhone/iPad. Start the clock at the sound (by hand, sound or hand/mic). Hold the camera towards the finish line if you also want to measure the total time.
The animation is available here.
A second version is available here.
They can also be downloaded for local playback from here.
In the second animation, the sound is delayed by 0.3 s (≈ 100 m). Try to start on the flash with sound distance set to 0 and on the sound with sound distance set to 100. It is important to note that filming an animation on a screen not is super accurate and that you will likely get errors in the second decimal when timing the square.
Test results
I ran three series of starts with the test animation. The two first with the start button in SprintTimer (on release), the first set by starting on the sound and in the second case with the delay animation and starting on the flash. The third test was a start on sound, but using a Bluetooth keyboard and pressing the space bar. I ran 10 tests of each and the result can be seen below.
| Average | Spread | |
| Start on sound | 175 ms | ±15 ms |
| Start on flash | 280 ms | ±40 ms |
| Start on sound BT | 450 ms | ±310 ms |
These total reaction times, i.e. my reaction and the system delays. That the human reaction to audio is faster than for visual stimuli has been noted before. But the differences shown here are larger, probably due to the latency in the sound input. The Bluetooth keyboard introduced not only longer delays but, worse, much larger variance. BT can therefore not be recommended when high accuracy is needed.
Thanks to Tinus Jansen, South Africa for the inspiration to this blog post.