Last weekend we visited the MTB mini downhill cup in Wijchen (NL). This race is held on an artificial ski slope and is the second race in a series of 5 races in The Netherlands. The best way to get to know the MTB Downhill sport is to do a real time test along with the official timing system. First thing we noticed, is the fact that CloudTimer is very well suited to time MTB downhill races. We also noticed that it involves more than just a start and a finish.
Last weekend, during Holland Cup 3 in the Netherlands, we did an important parallel test between the Alge Timy with start/finish beams and CloudTimer in manual timing mode. After a lot of lab & field testing, and development iterations we achieved great results in this competition.
The competition setup
The Holland Cup is a Dutch national race series. In this edition at the ‘Hooidonkse Kano Club’ about 100 runs were timed. For start and finish both beams connected to Alge Timy’s were set up. Also at both start and finish we had timekeepers with the CloudTimer app for Android. Further, three judging sections were set up with the CloudTimer Android app, and one race administrator was located in the race office to control all data.
The race went very smoothly. Although the timekeepers were mostly first-time-users, they did a great job. Also judging sections, in which ‘judges’ (read athletes) are rotating a lot worked great with the app. An important factor is that we had great connectivity at the course which off course is vital for the smooth functioning of the Cloud based timing system.
|time < -1||0%||Min||-0.54|
|-0.3 > time >= -1||5%||Max||0.50|
|-0.1 > time >= -0.3||
|-0.1 <= time <= 0.1|
|0.1 < time <= 0.3|
|0.3 < time <= 1||5%|
All result data from the CloudTimer app and Alge Timy system were compared into one file and the conclusion out of the data comparison was great. For the previous Holland Cup we still had some occasional large deviations when it came to the CloudTimer times. We quickly fixed this issue during the week and now the largest deviation between CloudTimer and Alge Timy was 5.4 tenths of a second(!). Which is pretty amazing for a comparison between hand timing (with untrained timers) and beam timing!!! We are particularly happy with achieving a 90% timing accuracy of max 3 tenths of a second. Also none of the deviations we saw had any impact on the medal table or further results.
All in all we can say that we’ve reached a level with CloudTimer where the system has been proven not only for low cost, user friendliness and instant results, but also for accuracy (compared to stopwatch timed races). Our next steps will now be to easily connect to timing beams. Although we can already do this, and have a timing accuracy of max 5 hundredths of a second with this setup, we still need to develop it a bit further. Mostly on the hardware side it doesn’t have the friendliness yet to be easily used out of the box.
Results are at results.cloudtimer.nl.
At CloudTimer we are doing a lot of lab and field tests to test & prove the accuracy of our sports timing app. While doing so we felt the need to clarify what this means: accuracy. Because a system can be extremely accurate, but that doesn’t necessarily mean that the timing of an athlete will be accurate. In this article we aim to give a high level explanation of the several factors involved in this topic.
In accuracy there are two things to separate: timing accuracy and system accuracy. The two will be further explained below.
What is timing accuracy?
Timing accuracy tells us something about the quality of the final results. It is a combination of the technical system, the operator of the system and the sport that is timed. A lot of effort always goes into the perfect system, to measure at a very high resolution or sample rate, but what happens in the field can have a great impact on the result.
System accuracy describes the quality of the clock in the timing system. When working with only one clock, the sample rate, and clock drift play an important role (i.e. when the clock indicates a minute has past, is this really a minute or maybe slightly more or less than a minute). When working with multiple clocks in a timing system, then not only sample rate and clock drift but also the synchronisation between the clocks play a role.
As was already above mentioned, timing accuracy is a combination of the technical system (with a system accuracy), the operator of the system and the sport that is timed. The operator can have a big influence on the timing accuracy when push button timing is concerned for instance. In this case the observational capacity [A] (when does the athlete cross the start/finish line), reaction speed [B] (how quick is the button pushed after an observation is made) and the reproducibility (will [A] and [B] be the same for all 100 athletes) of the timing operator have a very big influence on the timing accuracy. Finally also the sport in question has a influence on the timing accuracy. In cycling the front wheel is a very distinct marker to cross the start/finish beam (which will always be the same). In contrary in Canoe Slalom it is sometimes unclear if the bow of the canoe, the paddle, arm, body or water drop triggered a start/finish beam.
The question is, whether a very accurate system is needed to have a good race result. As CloudTimer (in stopwatch mode) is a manual timing system, the timing accuracy can be considered to be at 0.1 to 0.05 of a second. This accuracy mainly depends on the operator, not the CloudTimer system. The system should be at least capable of timing well within this timing accuracy. It must therefore be at least twice as accurate as the timing accuracy, which is between 0.05 and 0.025 seconds. Already in a previous article we showed preliminary results of our lab timing tests. In a next article we will show more results on to what extend CloudTimer is able to time in this range!
Our ambition with CloudTimer is to make race organisation/timing easy, but man, that’s hard! Last weekend we did the Holland Cup 2 at the Volmolence Kano Club in Waalre (Netherlands). With about 100 participants divided over the sprint, slalom and downriver it was again a nice step up from the last race.
The Holland Cup at ‘the Volmolen’ was again a race with typically late entries, a lot of categories, people starting randomly since they need to use each others boats, changing occupation of the judge sections, etc. This all asks great flexibility of the organisation and the timing system. Further we ran timing beams and Alge Timy clocks paralel to CloudTimer in order to compare the difference between the results of the two, but also adding to the organisational burden.
Running the timing & judging of the race was again very insightful as input for our development efforts. There is no better way to find out what to develop than to be in the field ourselves. We noticed amongst others some input errors since the validate button and the timing button are to close to each other. This can result in mis-clicking and overwriting a time. Still this week we expect to push a new version in which this will be solved.
Further, we are also working a lot on the online dashboard. Since during a race regularly scores need to be adjusted (due to transmission errors or protests) we made an interface to easily do this. Also uploading startlists is a new handy feature, and we now need to extend this to editing startlists since there are always changes to be made after a teamleader meeting.
All in all it was a challenging race to time with our app still being in a ‘beta’ phase. We are working on a lot of improvements for the next big release in two months from now. Maybe timing isn’t easy yet, but step by step we are getting closer to this ambition!
The result page can be found at: www.results.cloudtimer.nl/holland-cup-vkc.html
CloudTimer isn’t yet officially available in the app stores, but we timed our first official race! Canoe slalom Holland Cup 1 near Utrecht, the Netherlands was the decor for this milestone event. The Holland Cup is a Dutch race series governed by the national canoe federation.
Holland Cup Canoe Slalom Utrecht
With almost 40 participants and two runs during the day, CloudTimer worked well for the timing, judging and live results display for the event. Small races like these are very challenging, as in The Netherlands a tradition has grown to start at a random order. This is mainly because the athletes also need to do the judging. There were frequent changes in scoring device operators (transmission judges) which created some (human) scoring errors which later needed to be adjusted.
The app handled the random starts very well although this puts a strain on the start ‘judge’. The CloudTimer app permits to change categories during the race so athletes can be started at random order. For the judge stations a random start order doesn’t make any difference since participants are always displayed in the order of real starts (instead of planned starts). Some challenging situation occurred when athletes are overtaking each other during the race or finishing close to each other. CloudTimer can deal well with these situations with the ‘close finish’ function. But some timing experience is recommended in order to handle these situations correctly in a stressful race situation.
All in all, we produced nice results. The organising club was happy they could ran the race at relatively low cost, high flexibility and still maintain the quality of the results. We are looking forward to timing the next race in the Holland Cup Series in 4 weeks at the Volmolense Kano Club in Waalre!
Results of the Utrecht race can be found on results.cloudtimer.nl.
CloudTimer is developed to make sports timing as easy as possible without the need to invest in expensive hardware. To do so, we chose an everyday device aka smartphones to fulfil the timing and scoring need. But since a smartphone is not a professional real time timing device the question was raised if the timing accuracy is good enough? We used an Arduino microcontroller to simultaneously trigger start and finish at both CloudTimer and an Alge Timy3. We simulated a race with almost 100 competitors and found that the results showed a remarkable accuracy.
The test was set up with an Arduino microcontroller, connected to an Alge Timy3 and 2 smartphones. The smartphones were both Samsumg (S4 and S5) devices. The Arduino sends out triggers at a set interval to simulate a race of 93 competitors at 1 minute start intervals. The race time was set to 95 seconds. In figure 1 one can see that the time difference stays well within 0.020 seconds (vertical axis shows mili seconds), which pretty much proves the concept and the system. We will publish a paper in the next few weeks with accurate numbers of this comparison.
But is CloudTimer always as accurate as this? No, more testing has to be done. We found out that the system accuracy depends on the quality of the internet connection as well. A good and solid WIFI is to be preferred over a GPRS or 3G connection, while 4G has better results than 3G. However, we always found that we stayed within the 0.05 sec mark when comparing run times between CloudTimer and the Alge Timy3.
In addition to these Arduino “lab” test, in the next races will have a paralel timing system set up. CloudTimer will be used as stopwatch timing and start/finish beams connected to Alge Timy’s are used as a benchmark system. More results on this topic are expected soon!