SprintTimer can act as a starting gun, either by selecting a start sound, e.g. a shot, in connection with the hand start or by using the self start. Accurate timing requires that the sound is played at the same time as the clock starts. SprintTimer, therefore, uses low-level sound routines to minimize the latency when playing the sound. The delay is usually a few hundredths of a second. But the latency may increase quite a lot if you use a Bluetooth speaker, and delays of 0.1 s – 0.4 s are not uncommon. The purpose of this post is to give you some tips on how to mitigate that problem.
If you have access to two iPhone/iPads it is fairly easy to test the delay when playing a start sound. Place both devices on stands and align both at the same “finish line”. The finish line can be a line on a paper on the floor or on a wall. Set one of the devices to hand start and set it to play a sound at the start. Set the other device to start at a sound. Activate the sound detection and tap the start button on the other device. Both clocks should now be running. Start the recording and drag e.g. a pen over the finish line. After stopping the recording scroll to the pen on both devices and compare the times.
I tested this using the pendulum described in this post, but without the electronics, so it was just a version of the pen described above. I first used the built-in speaker on the iPhone. On average the time on the sound start device was 0.04 s behind. I then connect a decent Bluetooth speaker (JBL Charge costing about $100) and ran several tests. The delay was now 0.34 s on average. I further tested on a couple of Bluetooth headsets and in all cases, there was a significant delay. This is in line with other tests you can find on the net.
|JBL Charge||0.34 s|
|AirPods (1th gen)||0.24 s|
|AirPod Pro||0.18 s|
|Jabra JayBird||0.14 s|
Another test I made was to use the voice in self start as the start (setting the start sound to none). The voice uses other sound routines and could be expected to take more time. This was confirmed by the tests when a “Go” through the internal speaker was 0.20 s late.
Compensating for the latency.
Whether a 0.34 s error in the timing is acceptable depends entirely on the circumstances, for a 100 m race it is way too much, but for a cross country race, it is of little significance. Fortunately was the latency fairly consistent for a specific set up. You could, therefore, use the offset time in the start set up to compensate for the delay (SprintTimer v. 15.5 and later). Run a couple of tests like the one above and enter the difference as a negative value in the offset time. You can then run a final test and check that you get about the same time on both devices.
A wired speaker is better than a Bluetooth speaker. The latency in a Bluetooth speaker can largely be compensated for, but that requires a test set up with two iOS devices. For maximum accuracy, use an external starter and let SprintTimer detect the sound.