Last weekend, during the ROM 2013, a couple of SI-controls were out of sync. The overall times were correct, but for a few courses, the ones comprising controls 138, 148, and 163, the Splitsbrowser graphs looked awful.

I looked at the data sources (the line that looks like <PARAM NAME="src" VALUE=eventdata.php?eventId=6336>), and downloaded the file (after pasting the base-url http://www.splitsbrowser.org.uk/ in front of it.

Then, I inflated the file, which was compressed in gzip-format, using the 7-zip program, and looked at the contents.

I noticed that for some controls, the split-times were not monotonously increasing:

Jan-Gerard Van der T  [138:19]  87:11  02:03  03:21  07:39  09:49  12:20  18:23  20:31  21:25  23:23  28:46 139:29  34:23  37:28  40:09  43:54  46:19  -----  50:35  52:08  55:45  61:09  65:05 187:47  69:41  71:27  73:37  75:28  79:19  81:53  83:19  85:36  86:51  87:11

I found out that SI works a bit different than EMIT: the clock is in the control, and not in the badge, which means that the registered times may vary from control to control. It only works when all controls were synchronized, and that was not the case here.

But, no problem, I could correct the data file for that, if I would know the offset, how much the specific controls were off.

First, I looked at all the results, of all the different courses, and found in total three controls that consequently gave the wrong reading. Then, for the controls in my course, course 1, I looked at my GPS tracklogger data, and noted the difference in time between the wrong controls and the previous, or subsequent ones. I subtracted that difference from the time difference in the Splitsbrowser data files, and the result was the offset, for each of the controls.

This worked at least for 138 and 148. For 163, which was not in my course, and of which I therefore had no time information, I looked at the variation time difference between checking 163 and the previous, and the next control, and assumed that the ratio between the relative standard deviation of the leg time for the leg before and after it, would correspond to the ratio in distance, and thus in time. Thereby, I estimated what the offset would be.

Then, assuming an offset for all three controls, and with help of a couple of lines of Matlab code, I processed the data files, and uploaded them to my server.

So now, while the ROM’13 organization may upload the final results to the official site, you can enjoy a proper Splitsbrowser results page, on my own jgeo.nl-blogserver:

STAGE 1, March 9th, Vrachelse heide.

STAGE 2, March 10th, ‘t Zand.

The original Splitsbrowser pages can be found here: Stage 1, and Stage 3.

By the way, it is interesting to observe the time-spread in split times, or asynchronicity of the SI-clocks, by comparing the GPS-log speeds at the controls, for both an SI-timed- and an EMIT-timed event: