Heyho,

Just wanted to jot down some notes about how the computer/Ór side of the IOC went, while they are fresh in my head. May be useful for other large events. Might be teaching Granny to suck eggs, I'm sure others have hit some of these snags in the past, they were just new to me.

Day 1: Sprint

As part of the pre-checks, Marcus punched every control in the forest (both to wake it up and record its code) and then we did a download and print out to check all that stuff was working. Marcus noted one box had the incorrect code programmed into it, so a replacement SI unit was programmed, synced and sent out to be swapped - all good. All controls were in beacon mode with default 12 hours off time. They were initially synced earlier in the week from a good laptop time source, and had drifted very little. All the admin controls (Check/Clear/Start/Finish) were re-synced using SI-Master Sync box just before the event, and placed in their spots.

No major problems during the event - as it was the first day, several competitors turned up at download with a different SI number to what had been entered into Ór. I fixed those on the spot - usual symptom was a really long finish time, and their new SI number appearing in the extra downloads pane. I would find their actual entry in the left-hand side, open it up, fix the SI number, and get them to re-download - all fixed. This caused some minor delays, but no major queues built up. I also jotted these changes down on paper, as we needed to also update the entry list CSVs for day2/day3 in most of these cases.

One small issue was that I had difficulty selecting the entry on the day courses for competitors - If I put in their age class, their course was pre-selected (since age classes are mapped to courses in championship events), and Ór wouldn't let me change it. I worked around it by selecting the N/C box, but there's a better solution I only realised on Day 2 (below).

In the absence of a start control, we used the set of check boxes as "start units" in order to query the list of entries towards the course close time - this lets Ór show you who has actually "started" as opposed to entries who just didn't show up. This was slightly messy, as the records were spread out over 4 check boxes. We changed the protocol for other days to make one box the "master" check box - all competitors were asked to dib that box, as a safety check.

Online live results worked well - we had good internet coverage, and all maps/split sheets had a QR code that could be scanned to take your device to that page. At one point, we tried to hook up a real printer to make  set of paper results for the arena, but that caused issues with the splits printer, and a bit of a queue while that got sorted, so we quickly abandoned it. On subsequent days, we had a separate laptop and printer dedicated to just that job, and transferred backups of the event at intervals using a USB stick.

We went through roughly 2.5 large rolls of thermal printer paper per day, luckily we had bought plenty beforehand. People really wanted their split sheets, especially the foreign competitors.

Day 2: Middle

Same as previous days, Hugh and Brian pre-punched all controls, and we did a download and print out to check all that stuff was working. No issues found. Boxes had been synced earlier that week, and had drifted very little. All the admin controls (Check/Clear/Start/Finish) were re-synced using SI-Master Sync box just before the event, and placed in their spots - we tried to use the same good set of admin controls every day. Start personnel were instructed to make everyone punch a single specific check box as agreed the previous night (in addition to other possible self-service check boxes).

No major issues during the event - we had taken the list of SI changes from the first evening and updated the entries in Ór the previous night, so they didn't recur on the second day - we only had maybe 4 or 5 incorrect SI cards, mostly due to typos. Those additional changes were recorded on paper and fed forward into the Day3 entries later that evening.

The same issue around entry on the day cropped up, but Ruth had obviously had this issue before - there were special "Age classes" in the competition already, called "Yellow", "Orange", etc.. selecting those put the EotD competitors against the correct courses and in the results correctly.

The single safety check box worked well, and only one needed to be interrogated at the end to see who was left in the terrain.

We had no internet coverage, but the dedicated printing laptop, paired with USB exports of the competition, worked well. Don had made a large board with poly pockets on it so that result printouts could quickly be put up and be protected from the elements (which wasn't an issue in the end, but better safe than sorry.)

We had power onsite for day one, but ran all the other days off a single caravan 12v battery and an invertor. We had a backup battery we never used. The main battery was charged overnight each night.

Day 3: Classic

So, while all controls were visited in the morning to be woken up, we didn't complete a full download and printout, due to time - we were running short on helpers, so it was a bit frantic in the hour before first starts. This event had two remote finishes, which meant we needed extra finish boxes, and two sets of remote map collections too. Boxes had been synced earlier that week. All the admin controls (Check/Clear/Start/Finish) were re-synced using SI-Master Sync box just before the event, and placed in their spots.

We again used a single safety check box - worked well, and only one needed to be interrogated at the end to see who was left in the terrain.

Early in the event, i noticed issues with the time on control 210. It wasn't obvious what the issue was, so we went out and replaced it with a different synced unit (194) labelled as 210. My understanding was that this would then be easy to fix in Ór afterwards, but I had zero success adding the 194 control code as an equivalent replacement for 210. I need to test this process in my kitchen to understand how it is meant to work. In the end, as it was early, I simply changed the courses in Ór to expect 194 instead of 210, and resigned myself to manually fixing the small number of fake DNFs this caused after the event.

My troubles didn't end there - soon enough, two other controls (224 and 34) started to exhibit the same behavior - their start times were many (~11) hours in the future. These controls were too far out to easily replace, so I accepted that I would need to fix these all afterwards too (though I wasn't exactly sure how at that point). I had a quick glance at the Ór CSV database files and I was satisfied that the start and finish times were definitely correct, so I was confident there would be a way of fixing the splits.

We had good online results, though later in the day they stopped working. Not sure why - Ór said it was uploading ok. I suspect some bad data was causing issues. Later that night I discovered an extra "W35." class (note the extra full stop) was present instead of the required "W35" class, so I think this caused the issue (after the first W35 downloaded, and had no valid matching class) - it broke the final results upload later that night too.

The single safety check box worked well, and only one needed to be interrogated at the end to see who was left in the terrain.

So, I rushed away at the end to go back to the hotel to try and fix the results in the few hours before the prize giving (apologies to final runner, who had to suffer the indignation of a drive-by download station as I met him on the road from the finish). Once there, it became apparent that there was no easy way to fix the times through Ór. I backed up the competition, and opened the Results.csv file in the Ór database and started manually fixing the split times for each instance of a punch of the three broken controls (by searching for ';34;' for example) - in each case I just changed the hours:min of the split to be 1 min after the previous punch. In means the splits were not accurate for those legs, but they were at least valid - that's all Ór needed to be happy. This took roughly 60 mins, but at the end, all times on the affected courses looked correct.

I then went to fix the DNFs - in a similar fashion, I found all instances of control ';210;' and changed them to ';194;' - I took care to only do this for competitors who clearly had a fake DNF (i.e. it showed they had punched 194 at the right time and in sequence, but were marked as DNF for "missing" 210). Turns out, there were no real DNFs due to this anyways - i should have checked this quickly in Ór first, and then done a global search-and-replace. 30 mins later, and that was all fixed.

At this point, results all look good, but there was a final sting. Course 1 had two road crossings, each with an allowed time of 90s. Usually, you can do this in Ór, and it automatically takes care of the math. However, in this instance the planner hadn't realised that Ór cant handle the same road crossing in both directions - it will erroneously remove the leg coming into the first road crossing instead of the second time the control is visited (the actual second leg crossing). I chatted with the controller (John Casey) and we mad an executive decision to simply do the final calculations in Excel. We exported the splits from Ór, filtered out everything except course one, and did the math to remove the times taken for the two leg crossings, while being careful to add back in any extra time take over and above the allowed 90s for each. In the end, this made no changes to the overall positions, it just moved some of the times around a small bit. This was exported as a PDF to show our workings, and uploaded to the website for the elites to satisfy themselves that all was in order.

So, with 30 mins to go before the prize-giving's scheduled start time, results were uploaded to the website, and all was well again. I skipped the prize-giving, because I needed to go home to prepare for...

Day 4: Relay

The relay is traditionally a last-min job, because people usually dont return the declaration forms until the last minute, so you can't start preparing the entries until Sunday evening/night. We were prepared for this, having created a large master workbook in Google docs, so that multiple people could work on the same document in parallel, and I also had a bit of google-docs-fu auto-generating the data in the correct format for the final Ór import. You can have a look at a copy here:

<insert link here>

Rosemary, Paula, Anne-Marie and Myself split up the completed paper forms, and filled in the sheet over a few hours. At the end, I copy and pasted the data from the final page (Ór formatted), put it into Excel, saved as CSV, and imported into a blank Ór relay competition. This all went swimmingly, and we done by 12:30am.

Morning of the event, Angus, Neil and Hugh had been spooked by the previous day, and were out super early punching each of the 80(!) controls and we downloaded them all - making extra care to check the timestamps of the punches looked sensible. All controls were deemed in full working order. We synced and used a few spare controls to add duplicates on some high traffic sites. All the admin controls (Check/Clear/Start/Finish) were re-synced using SI-Master Sync box just before the event, and placed in their spots.

When people started arriving, any last-min changes required were completed in Ór. There were surprisingly few of them, I had mentally prepared myself for an onslaught. When the mass starts happened, I updated each category, and recorded the correct mass start times against each.

I only had a few small issues during the event - some runners had wierd times, usually caused by a missing start time - again, this was normally caused by a typo in the SI number. Edit the entry, fix the SI, and all was good. One team vanished on me (the J36 winners!), but i re-added it, and the runners magically repopulated. This left me with three extra blank entries I wasn't able to remove, but I figured I could fix them later.

A weird bug - if you have the team details dialog open, and a competitor ignores your pleas and downloads, it messes up the team - however, if you then reset the category from '[none]' to the proper one, it fixes itself, after a brief moment of panic.

Another wierd one - if a runner ends up having to run a second time, and uses the same SI a second time in a relay, i wasn't able to allocate them to the team - they were stuck as an extra download. I said I'd fix it afterwards.

Printing laptop produced results for prize-giving, and when I got home, I set about the final fixes. For the extra dummy runners in team 703, I just purged the records from the Competitiors.csv file - all fixed. For the extra downloads, I changed the SI numbers to unused values and updated Competitiors.csv and Results.csv to get them into the teams.

All working, uploaded final results, and placed laptop into bag. Cup of tea earned.

Aftermath

I took control 210 this morning and looked at it in Ór - its time was indeed reset to a date in 1945. Its also definitely one of the controls that received a battery change in the week before the IOC, as were 224 and 34. I opened the unit and checked the battery tabs and the solder - all look good and intact. To check for loose pads, I re-synced it, and smacked it (hard) off the desk several times, and was unable to trigger a time reset. I now suspect the root cause is human error (mine). I synced and checked battery levels in a lot of SI units in the run-up to the event, and I'm wondering now if I forgot to re-sync those units after doing the battery swaps. It would explain how they seem to be in perfect working order, but running off a zero time. Alternatively, maybe an SI-Master Sync box will only adjust times within a certain threshold of "out-of-syncedness" - I'd have to do an experiment to check that.

Brief Learnings for Future Events

• Sync everything in the week beforehand, in normal functioning SI units, the drift will be minimal (usually well below 1s)
• Check all battery levels and change where required (<3.15v) - make sure to resync afterwards!!
• On morning of event, check all controls early, download them into Ór and check all punch timestamps by going to into "edit->extra->who punches"
• Use Master Sync or laptop to do a final sync of Clear/check/Start/Finish before putting them out in the morning
• Have a backup laptop and splits printer, and lots of printer paper rolls (~2.5-3 per day)
• Print results from the backup laptop, not the main one
• Make everyone punch a single check box, so you have a unit to download into Ór at the end, to see whos actually started and left out.
• Make sure you have fake age classes for the entry on the day courses.
• Have a battery power solution, and a backup battery, and a plan to charge them
• Be familiar with the Ór import CSV formats for individual and relay events, and the Ór database files. Be prepared to edit them.
• Know how to backup Ór events ("Export->Competition")
• Allocate rental SI numbers ahead of time, and have them in envelopes for collection. Have them pre-entered into Ór.
• Make sure planner is aware of Ór limitations around road crossings.

I think that's about it - any additional questions/comments/observations, let me know below.