Brisbane WICEN’s first Emergency Communications Exercise of the year took place this last week-end at Stirling’s Crossing, assisting them with the running of the Stirling’s Starter. This is an annual horse endurance ride event organised by Stirling’s Crossing Endurance Club and is the first such event on their annual calendar. For this event, we were assisted by members of the Gold Coast Amateur Radio Society.
Being the first event of the year, we’ve got the added challenge that we’ve had equipment in storage for some time. The base computer database system often gets worked on during this off-time to address bugs and generally maintain the system, so this first event is often one where technical gremlins rear their heads. Nonetheless, in a genuine emergency, one must be prepared for the possibility of equipment failure and thus have back-up plans in place.
For this event, we brought the usual assortment of equipment including a number of VHF/UHF dual-band radio transceivers, some AX.25 packet radio equipment, and the computer system. It’s better to bring everything up and leave it packed away than to get there and find some critical piece of kit was left behind.
Friday
The journey from Brisbane took place on the Friday and we arrived at Imbil in the afternoon. Sufficient time to park the caravan, set up an awning and run power and drainage feeds, then call it a night. As the event wasn’t due to start until 1PM and could be pushed back as late as 3PM due to heat, we’re in no hurry to set up.
Saturday
Setting up
The morning begins with a visit to the coffee vendor for a morning brew and some breakfast, before unpacking and set-up begins in earnest. Set-up is a fairly quick affair, even for this event and by 10AM, we had a base radio (which was operating simplex 2m) and the base computers all set up ready to go. The only thing needed from here was for the people with the repeater to arrive, so that can be set up in its usual location (near a cottage overlooking the base), and for the ride organisers to provide a listing of all the competitors details so we know who to expect on-course.
By this time of the morning, quite a few people have arrived at the venue.
Early noon
By about 1:15PM, from the WICEN side we’re more or less organised, with positions for operators all figured out and the WICEN base computers programmed up with the route that will be taken by the competitors. For this event, we have four rides going; a 80km ride, a 40km ride, a 20km ride and a 10km ride. The bigger rides are broken up into 40km “legs”, and it’s common for multiple rides to share common “legs”. This makes the route configuration a copy-and-paste affair: punch in the 80km ride, then for the 40km, just duplicate the “leg” they share with the 80km riders.
What’s missing at this point, is a listing of the competitors numbers that have been allocated, the ride manifest. We usually get this in two forms: a CSV spreadsheet on a USB stick, and a hard-copy version.
As we’re not using the RFID packet reporting system on this event (despite bringing some of the equipment needed) either form is fine. CSV’s easy because we just upload it to the computer after some gentle data massaging, and it programs in all the competitors for us. Paper means we’ve got to figure out the contiguous ranges (taking into account skipped numbers), and program those in by hand… and it also means we’ve only got competitor numbers in the system meaning if someone asks “What checkpoint is Mary Smith last seen at?”, we just shrug our shoulders, since we don’t know which 3-digit competitor number she was allocated.
With GCARS assisting, this event we had quite a few operators, which is a nice luxury. It means a much easier time for checkpoint operators since they can load-share (with one taking down numbers while another radios through prior scores), and in some cases, it’s even possible for us to collect meal requests over the radio and bring lunch out to operators.
Alas Murphy smiled on us on this occasion, a flaky microwave oven tripping power at the catering site caused the catering van operator to lose their patience and leave. Thus, we’ve got a spare person to bring meals out, but no source to collect them from… so alas we wound up surviving on our own rations anyway.
The first leg
After a delayed start, the event started in earnest. There’s a non-zero chance when an event starts, that it starts without the ride manifest being provided to us (in any form), and thus us knowing what competitor numbers to expect. Naturally, this is exactly what happened. This actually does hobble things quite a bit, you never know a check-point is done if you do not know how many competitors are in the ride to begin with.
We can infer that everyone that passes through Checkpoint 1 will eventually be seen at Checkpoint 2, but it’s an educated guess.
Furthermore, during the actual run, a bug was discovered in the server code, thankfully only requiring a one-line fix that could be applied on-the-fly. Paper logs were used to capture all the times, then once we had the rider manifest loaded in, a bit of fast-and-furious data entry later, we were caught up and ready for the next scores to come in.
Most of the rides for the Saturday were nearing completion by 4:30PM with the competitors all being counted through all but the final check-point. Once back in, we were able to have some dinner before the 80km riders went out on their second leg.
The second leg
The second leg started around 7:50PM, and with these events, it’s always a question of how late the competitors leave it to actually commence the next leg of the journey. Some gamble with leaving later in the evening, with the idea that in the cooler temperatures, they can maintain higher speed. This does rather, drag out the day, for the check-point operators who must be ready for both the first competitors and wait there for the last competitors.
We estimated that if the competitors didn’t leave by 9PM, they wouldn’t make it through the course before the cut-off time. As it happened, at 9PM, we got a message from the ride organisers that indicated nearly a third of all competitors in the 80km ride, had withdrawn. By this stage, we were only left with 3 riders that hadn’t yet been seen at the first check-point. A few minutes later, two of the three were seen, and 30 minutes later we got confirmation that the one left behind was staying behind… so we had our field and knew who to expect.
By 10:55PM, most of the competitors were back, but we were waiting on a final four competitors. The ride organisers gave us a break finally at 11:45PM, taking over the final check-point so we could finally close up and get some sleep.
Sunday
Setting up
The next morning began at 4:00AM, with setting up the ride tracking system for the day’s rides: a 40km, 20km and a 10km ride. The ride manifest was ahead of time, but due to a mix-up, it seems one of the files is a duplicate file. So we’re still missing one of the rides’ competitor number allocations.
The ride began at 5:00AM, and things seemed to go fine until the back-end database running the ride came to a screaming halt at 6:15AM. The database process was going into lala land, with memory usage sky-rocketing until it exhausted the available memory of the base computer. Taking a back-up of the database and restoring it on the other base computer was no help: it did the exact same thing. So, with the computerised system out of commission, it was back to the old faithful system: the dead tree database engine…
Thankfully, with some careful thought and a few database indexing principles applied, a paper log can perform reasonably well. Not as fast as the computer, and definitely not as good for multiple-operator access, but good enough under the circumstances.
By 10:25AM, most of the field were back, but some riders were taking it easy in the heat so as to not stress their horses. By 11:00AM, the final competitor was floated out, and we had the afternoon to grab some lunch and catch up on much-needed rest.
Final comments
Being so early in the year, this event winds up being one of the more challenging events in the ride calendar. Not only does a competitor need to navigate the course, but managing their own health and that of the horse in the heat is paramount. Heat stress can lead to disorientation, causing a competitor to become lost in the forest and can be fatal to both the rider and the horse if not managed.
It is for this reason groups like us provide a pivotal role in ensuring the safe running of these events, providing the necessary bridge between the ride organisers (for whom rests the responsibility of ensuring competitors’ welfare), and the competitors in the field. For this to happen, we rely on certain tools to implement that communications channel. These tools however are not 100% fail-safe, and so the end-game is one of providing fallback systems that can be quickly switched to and implemented at a moment’s notice if a primary system fails. In doing so, we continue to provide a valuable service in spite of equipment failure.
A special thanks go to the members of the Gold Coast Amateur Radio Society, who assisted us on this event. Extra hands made running things a whole lot easier with your help.
(The Mastodon thread of this event written on the day can be found here.)