Skip to main content

I have had an interesting question raised by a client regarding live timing

They do something different than what I would expect so here goes.

They have two keys and run the NAT /FIS on both
First run everything is normal, primary pc on line, registered race on live timing , etc. Back up PC running independent and that PC never registered race so it is assumed that it cannot post the backup times even if they forget to uncheck the "SEND DATA" box
AT the end of the first run they copy the primary race files and place them on the backup computer so that the bibo matches etc for the second run.

The 100000 dollar question is...

Now that both PCs have the "primary" race file for the second run


Does the live timing registration and parameters come over as well?

Yes, they do, they're associated with the "race"

Could the Backup PC now compete with the primary to send data to live timing?

Yes, and it's happened. The solution is to make sure the "send to LT" button is unchecked on the backup.

Assume for the argument that the button for "send Data" is still checked.

So now there is the possibility that the wrong times could accidentally be sent or have you trapped out that possibility?

No, I haven't seen a way around it. It's just a matter of being aware of what you're doing and un-checking the box on the backup (if you choose to do it this way, which I don't think you should be in the first place, because you're potentially losing the backup times from the first run)
Original Post

Replies sorted oldest to newest

This is one of the situations where SST doesn't inherently prevent operator error. The other major one is the possibility to have data for male and female athletes in the same file, and to potentially send timing data to the wrong gender. Both situations can be avoided by establishing 'safe work practices', like the one posted above. I have a pre- and post-race checklist that includes the same practice of switching off live data transmission from the B timer. It also includes saving the B timer file after first and second run in case those data are needed later.

Other software platforms have different approaches, building in the structure to remove these possible situations altogether. In dTris, for example, males and females must be in separate files. If you're using Vola or dTris, live timing publishing software isn't part of the timing software but instead it runs on a separate computer networked to the A timer. The B timer data simply can't make it to the live timing site.

Some view this possibility for pilot error as a weakness of Split Second. But the potential areas of concern are well understood and can be handled by simple operating procedures. There is a gain in versatility and simplicity as a result. It's nice to have timing and live publishing integrated in one package, and the software fees include web hosting.

Add Reply

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