The RaceTec Blog
News and views from my timing world

WHAT: Indian Ocean Classic
WHERE: Perth, Australia
WHEN: 28 Jan 2012
HOW: AMB Prochip
WHO: Contracting to Multisport Australia

This race is actually associated with the Surf Ironman series mentioned in the next race below this one. This one is open to members of the public, and involved a swim, beach run, surf ski and board paddle up and down the coast.
What made it stressful for me was having to manage 4 remote timing points down the coast, which all had to bring data back live so I could push it to the website.
Remote timing points are all about planning and management. You HAVE to have someone you can trust looking after them - setting them up, making sure they keep running, and packing them up. And the person who goes off to do it needs to be resourceful and have a good amount of common sense. Fortunately I had someone like that, and I was able to concentrate on the start and finish.
After a shark scare during the swim leg caused the race to be delayed for an hour, things finally got underway, and the race remained relatively under control after that. I was having some weird issues with the AMB equipment I was using, which was causing my connection to the readers to drop out. So I had my fingers crossed when the first guy crossed the line. Of course he happened to be someone who lost his timing chip, and the familiar beep was horrifyingly absent ...
I have been taught never to run at a race. Always look calm and relaxed, even if things are crumbling down around you. Well, I can tell you, it was a long (brisk) walk to the finish line to make sure the manual backup process was in place! As it turned out, the AMB readers were reading and storing data fine, it was only the connection from my PC that was the problem. Once I sorted that out it was all fine.
For the main event on the Sunday (more on these below), the television production vans were rather inconsiderately placed about 250m away from me, which left me with the problem of getting a network connection to them.
Now, I've always wandered about the 'maximum 90m on an ethernet cable' story everyone tells, and now was a good a time as any to test it. I strung together about 300m of cable. 3 lengths of 100m. The one join was done using a battery powered switch (nothing fancy, just a small, standard 8 port one), and the other join was done using a basic network cable 'joiner' which I happened to have in my bag (no timer should be without one).
Well, my TCP/IP connection to the broadcast vans stayed up 100% all weekend. Yes sure, maybe it wasn't a full 100Mb connection, but let's face it, that's not needed for the kind of work you do when timing.
My internet access from the local surf club was via a Ubiquiti long-range wireless link. These guys have some really well-priced gear that is well worth looking at for those events where you need long-range network connectivity. http://www.ubnt.com. I promise I am not associated with them in any way, so I have no ulterior motive to push their products.
It didn't help that this was one of Perth's hottest days of the summer. 42 deg celsius, and no wind to cool things down. The drive home, to a cold beer and spa, in an airconditioned car, never felt so good!

WHAT: Kelloggs Nutrigrain Surf Ironman Series
WHERE: Various coastal towns in Australia
WHEN: 18 Dec 2011 to mid-Feb 2012
HOW: AMB Prochip
WHO: Contracting to Multisport Australia

Well this is race timing with a difference. The gig involves a series of 7 events around the country, and the brief from the organisers is to provide a live leaderboard directly to the TV production so that a leaderboard can be displayed live on screen.
There are 21 male and 20 female competitors, who do various race formats involving swimming, running, surfskiing and paddle boarding. I have to set up timing points on the beach (exit and entry to the water) as between each leg they come back to the beach and do a short run before the next leg. Then there's a separate finish line.
I won't bore you with too many details, suffice to say it's a few hours of intense activity, during which no mistakes can be made. I had to develop a new TCPIP socket interface for the TV graphics guys. On top of this, live leaderboard data comes from a helicopter to me, I capture it into the leaderboard capture program in RaceTec, and then notify the production crew that it's ready for display. The data from the timing points is sent automatically within half a second of a split point being crossed.
In between this, the usual running around for people who lose chips, trying to get info from officials, etc.
Fortunately I don't have to produce any results - for the individual races or the series. That is done manually by officials, and I'm happy to leave them to it!
Handy tip #879: When the organiser says the closest accomodation they could find for you is 2 hours drive away in heavy traffic, you can bet that's because the hotel is a sponsor and that's where they can get you a free room :-)

WHAT: Ironman Western Australia
WHERE: Busselton, Western Australia
WHEN: 4 December 2011
HOW: AMB Prochip
WHO: Assisting Multisport Australia

Most of you won't be aware that Ironman was the main 'breeding ground' for RaceTec's advanced features. Those early days 10 years ago (working with Multisport Australia) were highly stressful for me, I remember spending many hours before, during and after race day frantically coding changes, bug fixes and improvements. It's a huge relief to now be able to handle registration and race day without having to make any source code changes, it means I can focus on other things, and think up new ideas.
If anyone asks you to quote on timing an Ironman, I strongly suggest you mumble excuses about having a family, children, sanity, free-will ... and walk rapidly away in the other direction. It's a long, hard 24 hours, which will stretch your resourcefulness and abilities to the limit. Anyone who tells you otherwise is not doing a good job of it.

In the early days, it was good to soak up the atmosphere during the race, but I must admit that I now prefer a nice quiet timing office with aircon and the tools to monitor all the timing points and data flowing in (a cold beer would be appreciated too, but we need to maintain a level of professionalism!).

I wonder if competitors appreciate what race timers do for them sometimes. At Ironmans, one thing we always do is ensure that everyone who enters the water for the swim, exits the water. If not, the organisers need to be notified asap. I doubt there is a competitor out there who realises the timing guys are helping to look after their safety.
Do you think they know that if we don't see them go out on the bike leg, then we have to rummage through their wet swimming gear looking for their chip, which often gets pulled off their ankle when they tug their wetsuit off? Then we have to run around trying to get that chip back to them somewhere on the bike leg, or find their running kit and put it in there, so that they at least get some run splits and a finish time.
For all the times I've done that, no one has ever come to say thank you. It's a thankless job, ain't it? But someone has to do it ...

Handy tip #267: When the announcer goes quiet and starts rambling on about the weather and other arbitrary stuff, the chances are someone is looking for you because their network has gone down and the commentator display isn't working :-)

Sometimes it's the little things that become the biggest annoyance on the day. If you didn't already know it, RaceTec has a nifty medical tent module for recording who enters, what was wrong with them, and when they exited. You can also print a handy medical treatment sheet, and the medical staff have access to any competitor medical information that may be important to know. Unfortunately these medical 'tents' are invariably far from the finish line where your network is laid out, so you invariably spend your day sorting out their connectivity issues. I speak from experience here :-(

A large part of the stress with an Ironman is knowing that at 8:30am the next morning, competitors bid for slots at the annual finals at Kona in Hawaii. So you don't want to get it wrong, or leave someone off the results by mistake. These guys take Kona as seriously as my dog treats her trips to the beach. They don't want to miss out!

Of course working with a timing company as experienced as Multisport Australia does make things easier. But it also means I'm stretched at every race trying out new things. Which is not a bad thing of course, it means RaceTec is continuously being improved.

I know I harp on about this, but keep an eye on your Results module to make sure that the processing is going quickly. With close to 30,000 splits, these big triathlons keep the Results module busy, but even then I didn't see processor usage climb above 50% on a standard laptop, and that was only short bursts when results was running. Remember there were a few commentator displays running at any one time, live exports to ironman live, etc, etc. Calculating all times and positions (including all split positions) only took a few seconds. When you consider that RaceTec was having to calculate 270,000 positions every time (not to mention calculating split and finish times for a complex split setup), then you have to admit that SQL Server can deliver when required. I did re-index once during the day.

WHAT: RACV Energy Breakthrough
WHERE: Maryborough, Victoria, Australia
WHEN: 24 - 27 November 2011
HOW: AMB Prochip
WHO: Contracting to Multisport Australia

This is a fascinating event. To get an idea of what it's about, check the website.
Basically there are 2 tracks, a 24 hour race on each track (running at the same time), and some other events ranging from short to 14 hours or so. So it's a pretty busy weekend.
The big deal here is that in the main race, the competitors do over 600 laps in 24 hours, so they are riding nearly 700 kilometers. Not bad for vehicles made by high school kids.

So anyway, anyone doubting the stability of RaceTec, hear this. I had 2 licences used - one on each track. Each licence had to run results and live-to-web every 10 seconds, for 24 hours at least. At the end of the races, RaceTec was computing results for nearly 50,000 splits on each track. So every 10 seconds, the results module was searching 50,000 splits calculating fastest lap, slowest lap, average lap and number of laps. As well as current overall and category positions. And it was doing this in a couple of seconds.
I used the new multi-lap setup, so RaceTec created new splits as required, there was practically no setup required from me. 600 splits created automatically is a big help!
The only issues I had all weekend was with competitors swopping chips by mistake.

I used the time I had (a 24 hour race is a long time. Feels much longer than 24 hours!!) to do a lot of work on my new criterium/laps module which is coming on nicely. Basically what you have is current results and standings on a screen in front of you, updating automatically as you watch. Imagine the Enquiries grid having finish times auto-filling in front of your eyes without having to click a refresh button. I still have a fair bit of work to do to this module, such as a quick print button which can print nice looking results at any time, or on an automated basis. For these long races, organisers like regular printouts of current standings.
Admittedly a lot of you won't use this often, however when you do need it, I know you are going to appreciate it!

Of course using AMB technology at an event like this makes things much easier - remember the competitors are hitting speeds of 70km/h, and you just can't afford any misreads. If you miss someone when using AMB it's because they didn't cross the timing point. Period. It gives the race timer a huge level of confidence when arguing missing laps with competitors.

As with all multi-lap events, the start and finish are the aspects you have to think through carefully. I will probably update the help file with my experience from this event, especially regarding which start type to use. The criterium/laps module will have some useful functionality for handling starts. Remember, for these type of events, time is not critical, it's all about lap counting. So often there's no real start or finish time for competitors. This is something a regular race timer has to get his mind around. And it's something I need to handle seamlessly in RaceTec.

WHAT: ITU Triathlon World Cup
WHERE: Auckland, New Zealand
WHEN: 20 November 2011
HOW: AMB Prochip
WHO: Assisting Multisport Australia

OK, so ITU triathlons are usually pretty damn full on weekends. Which makes it really annoying when you get food poisoning the night before, and spend the day staggering around like you've got the plague.
Fortunately I wasn't the only one there, I was only assisting Greg from Multisport Australia, and my responsibility of providing feeds to the ITU results site and the television production went off without a hitch. Not that I remember much of it.

One thing I need to mention after this race - and I know I mention it often to RaceTec users - GET YOUR SPLIT SETUP RIGHT! Sure, RaceTec makes it easy to change your race setup mid-race, but it's not a headache you want when there are other pressures on. If you get it right, RaceTec will be your best friend on race day. Get it wrong and you'll be emailing me with a subject header of "Help"!
The setting that seems to catch people out the most is the minimum lap time. My personal opinion is that this value should be used for preventing duplicate chip reads in silly situations. The closer you put this value to an actual lap time, the more chance you will get it wrong and spend an hour wondering why RaceTec isn't on your side.
A value of 00:00:20 is more than good enough for most situations.