Audited Final Results of the 2015 Icarus Florida UltraFest races are now posted online.  You may view these results by clicking on the following link:

 

http://my2.raceresult.com/46570/?lang=en#0_C1B870

 

A PDF file of these results can also be either viewed, or downloaded, by clicking on the following link:

 

http://mcmtiming.com/wp-content/uploads/2015/12/Icarus2015FinalResults.pdf

 

I have posted the lap-by-lap split times from the 2015 Fall Icarus Florida Ultrafest races online so that each individual runner’s splits are available to either view or download.  These splits are in Excel spreadsheet format, and any or all of them can be viewed or downloaded by clicking on the following link:

 

https://drive.google.com/folderview?id=0By7VYIPT7VbnY3ZmX0ZVRkFHX2s&usp=sharing

 

I am deeply sorry that posting these results took so much time. I take my task as official timer and scorer very seriously, and when I post audited final results, I want to be sure beyond any and all doubts that I am posting accurate and complete results of the race, results that are defensible and will hold up under any and all scrutiny, and results that will be acceptable for any records ratification.

 

I have spent well over a hundred hours in the past three weeks since the race ended reviewing each and every lap run by every single runner. I offer this only as an explanation for the huge delay in posting final results, and not as an excuse.

 

Last year’s race involved about 40 runners, with 10 runners in the 6-day race. A total of 7,753 laps run was run among all runners and all races. When the race finished up, the next race on my work schedule was six days later, and it was the Azalea 12/24-Hour races in Palatka, Florida, a small event with about 30 runners running 2-mile loops, followed a few days later by the Palm City Turkey Trot 5K, a 600-runner event.

 

When last year’s Icarus event finished, I worked full-time, all day every day, to process and confirm each of the 7,753 laps run, so that final results could be published. It took more than a week for that to happen, and the final results were published the day before Thanksgiving, 10 days after the end of the races. I immediately jumped into a heavy holiday race work schedule.

 

This year’s race comprised 66 runners, with 25 runners in the 6-day race, so this year’s field was both larger and the large 6-day contingent meant that lots more laps were run. The race that ended three weeks ago finished with a total of 15,608 laps, more than twice as many laps as last year’s race.

 

In order to ensure the highest degree of accuracy and reliability, I used two completely different timing systems, each of which produced two complete sets of timing data. To produce final audited results that I can have confidence in, I need to compare both sets of results and resolve any differences or conflicts between the two sets of runner data. I’ve tried to find a quick and easy way to do this, but those attempts did not give me confidence that each of you were going to be credited with each and every step you ran, so I compared every single lap for both sets of data with each other, one by one, reviewing all 15,608 laps.

 

Unfortunately, this year’s Icarus race was much closer to Thanksgiving – it was just four days before that holiday. When I left the race site this year, I was immediately plunged into working pre-race prep for packet pickup, then directly into the Turkey Trot, and then into a hectic schedule of working four different races in the 14 days after Icarus ended.

 

Holidays are hectic times in and of themselves, and mine was no different than yours. I had family visit from across the state of Florida and from Minnesota on Thanksgiving and the week after.

 

I did everything I could to process the Icarus results quickly as possible, but it was not nearly good enough this time.

 

Why is it so time-consuming to check the results? Each system produces a huge database of times that need to be confirmed for accuracy. It seems that it would be simple – just count one lap for each time a runner crossed through the finish area. But that’s not how it works ;-).

 

The process starts with a runner wearing an electronic timing chip of some sort. For Icarus, I used two completely different timing chips – one chip was an ‘active transponder’ attached to a neoprene rubber ankle strap, and two other timing chips were glued to the back of each race bib.

 

The ankle-strap chips are small radio transmitters which broadcast a signal that the timing box at the finish line receives. The signal start being picked up within a couple of feet of the timing area, and continues to be picked up until the runner is more than a couple of feet past the timing wires. This system is incredibly accurate and reliable, since the chips are constantly broadcasting a signal to the timing mats. But these chips are expensive, which makes using them in a large race very cost-prohibitive.

 

The bib chips are passive, and are activated when they enter the magnetic field generated by the timing mats, and when activated, they ping a signal back to the timing mats that is then read by the timing box. This system is highly reliable, but less so than the active transponder system. The bib chip system is much less expensive, but is much more affected by extraneous factors such as body mass, water, and weather.

 

Each time a runner passes the timing area, many ‘pings’ are generated, and it’s the job of the timing box to decide which of these many ‘pings’ is the ‘best’ indicator of the ‘true’ time the runner passed the timing area. Lots of algorithms are used for this, so that in the end one ‘best’ time is generated by each system. But the raw timing data shows LOTS more pings than are eventually counted as valid by the system. This helps ensure that AT LEAST one ping gets counted each time a runner passes the timing area.

 

If this were the only factor that came into play, calculating the final results would STILL be easy. But the really complicating factor is that runners are human beings. And humans are fallible – that is, they make mistakes. They forget which direction they’re going, they cover their race bibs up, they crinkle, fold, bend and mutilate their race bibs, they forget to wear either their timing ankle chip or their race bib or both, they cross one timing mat and then stand and talk for minutes before crossing the second timing mat area, they stand near the timing mats for a minute or more (generating lots and lots of timing pings), they cross the timing mat on their way to the aid station or bathroom, and then they cross it again on their way back, and they cross it before and after entering their tents.

 

In short, there are LOTS – hundreds – of times when the timing system pings that it counted a valid lap when in fact a valid lap was not run, or when a runner crosses the timing mats having run a valid lap that was not counted by either system (for reasons of not wearing a timing chip or chips).

 

That’s why I strive VERY hard to have someone in the timing tent area at all times, in order to confirm that your valid lap is indeed counted. In the 150 hours I worked the race, the longest continuous sleep I took was a bit more than two hours. In every sense, this was as much an ultra for me as it was for you ;-).

 

Having two separate systems working at the same time vastly simplifies fixing errors, since any time there’s a disparity between the total laps on one system as compared with the total laps on the other system, that’s our cue to investigate and resolve the conflict.

 

I made hundreds of corrections between the two systems, removing invalid laps while adding in valid laps, and we have a record of all those manual corrections. So simply comparing the ‘raw’ timing data that each system generates is not enough – each system will include both invalid laps that need to be removed, as well as missing valid laps that need to be added back into the totals. This is what makes comparing one set of data with the other set of data such a time-consuming process.

 

I remain deeply sorry that this process took so much longer than I expected, and I very much appreciate your patience and tolerance with this. I remain dedicated to providing you with the best possible race results, and I am more than happy to discuss this further if you wish. I can be reached at mike@mcmelton.com, via Facebook, or via cell phone at 772-349-1704.