Skip to main content

I've been asked to time a cycling time trial next year. No big deal, I've done a few of these. But this one has a challenge: start-to-finish communications and data transfer. It's a road hillclimb event with the start 10 km (6 miles) away from and 600m (2000 ft) lower than the finish. The finish is in a ski resort village and has cell coverage, but the start is way down in a narrow canyon and has no wireless service. There is substantial terrain between the two and I would not expect VHF radios or wireless ski timing to work, although I'll check over the winter. There is a landline near-ish to the start, at a ranch. I haven't approached the owner yet, but it might be possible that we could have access to that phone line.

Obviously I need start-to-finish communications, and data must be transmitted somehow as well. I have sought quotes for chip timing, although with only around 100-120 athletes expected, this will be expensive. And it doesn't solve the issues of communications either.

I have cycling specific software that accepts data from SRT timers connected to photocells, and it can be set up to use hand-entered start and/or finish TODs, so I guess I could keep a voice line open for the whole event and transmit data that way, but I'm wondering if there is a better way. Over to you guys.

Wally
Original Post

Replies sorted oldest to newest

There are a few ways around this. But first, what is your specific requirement for communications between start and finish? Very often there is none and I utilize an assigned start time and make adjustments if there is an anomaly at the start. If you'd prefer to have a impulse based start time, does your software allow for an import of the SRT data? You could deliver the start timer to the finish and import the data after.
Posting a start list with time of day for each competitor is standard practice in cycling, and yes, in theory you could start each rider on their correct posted time without confirming start order to timing. The handful of variations could be accounted for later on. It goes against the grain to have no direct start-finish communication, though. I confess I automatically began to reject this concept, but looking at it from various angles, it's not as bad as I first thought. I know the software designer so I'll call him and ask if it can accept a bulk import of data from the start. I guess if we can start them all on 30 sec intervals and we don't have many more than a hundred entrants, then I'd be almost be able to get to the top by the time the first riders are finishing. At that point we would have to overcome the issue of accepting ongoing finish line data whilst the start data are imported.

Add Reply

Post
×
×
×
×
Link copied to your clipboard.
×