Skip to main content

pi-timer [1)With split second now allowing connections to two timers, I thought it would be a good opportunity to think about some new methods of wireless timing.

Per the FIS timing booklet, all homologated timing solutions require the use of 4 synchronized timers: System A and System B at both the start and the finish. It does not specify exactly, however, how data transmission from the start must occur. Per page 10 of the timing booklet:

"This allows race organizers to use many types of timing solutions without wires as long as these 4 timers are in place and are used to verify the results. If times are generated by a timing solution other than system A or B in all cases these times must be checked against system A and must match exactly. In case results deviate from system A, the competition must be evaluated on the A system times as per the normal timing set-up rules and procedures"

Many of the systems currently commercially available in the US use radio transmitters to send impulses from the start to the finish, and correct for the delay. The disadvantage of this system is that it invites the possibility for the wirelessly transmitted impulse to disagree with the impulse recorded to tape at the start. Because impulses cannot be recovered, a lost wireless impulse could mean going through an EET procedure to recover from tape at the start.

My goal is to send the actual Time of Day data from the start timer, not impulses. This removes the possibility of any disagreement, however small, between data collected at the start and at the finish.

Using the new "2nd timer" functionality of split second, it is possible to connect both the System A start timer and the System A finish timer to the software simultaneously to produce real time results. The problem is figuring out how to connect a timer with a serial port to a computer that is far away.

To solve that problem, I used a $10 Raspberry Pi Zero W microcomputer and some custom software. The Raspberry Pi is connected to the serial port of the timer at the start, and uses the internet to send data from the timer to the cloud. It can work off of any available internet connection, wired, WiFi, cell phone hotspot, etc.

The results PC at the finish runs software to read the timing data from the cloud and send it to a virtual serial port. Split Second (or any results software that supports 2 timer connections) can then read this data.

The main drawback of this approach is that it depends on an internet connection. However, with the constant expansion of wireless networks and the increasing availability of internet connections at ski resorts I think this problem will continue to get smaller. I believe that the simplicity and low cost warrant some further investigation, and I would love to collaborate with anyone who is interested!

I've attached a diagram of my longwinded description, and a YouTube video of it in action in my living room.

Zach

https://youtu.be/BDw4caEM4UI

Attachments

Images (1)
  • pi-timer (1)
Last edited by zhenry
Original Post

Replies sorted oldest to newest

Great concept Zach. As you said there are many way to send wireless data. Fred Patton has recently proved the use of Raveon data modems to be a simple and powerful solution to sending ToD to the timing building.

A couple points for clarity, if I may.

The FIS does not allow for the wireless transmission of finish impulses. Photocells must be attached to the timers via wire.

You note the potential for missing impulses, when only sending the signal rather than data. That is always there lurking in the background and anyone who has tested this has seen it. While the impulses are missing at the finish, they are captured and printed at the start. This is the reason for the 2 timers connected to the start wand, to capture that data. There is no need for an EET, as the ToD tapes can be entered into the software as valid times. While this is not the most expedient way to time, it can be done and is valid without any further calculation.

You could always ski the 2 timers from the start to the timing building and download the data. If you could get past the line of parents and coaches looking for times!

Matt

Thanks for the reply!

I realize now that I don't have wires from the photocells in my diagram. That's just an omission on my part, not a design. The photocells should be shown as plugged in.

If you are sending impulses from the start and capturing to tape as a backup, is there not still the possibility of a disagreement between the impulse on the tape and the impulse that traveled through the air? Do you not have to account for this if you miss an impulse, and have some racers with wireless impulses and some with impulses from the tape at the start timer?

Again, thanks for the reply. We haven't been doing much racing this year but I've been enjoying thinking about this stuff.

Zach

That is generally the concept we have been using for over 15 years in multiple configurations using Serial Device servers. They convert the serial ports to IP data on the network and using virtual serial ports on the computers.  We use MOXA devices:

https://moxa.com/en/products/i...rs/nport-5400-series

In the timing shack we have multiple Alge S4's, Output for display and an output for datalog all connected to a moxa that is nailed to the wall and connected to the network.  This allows the laptop timing to be on the network, but does not require you to be in the timing shack, you could be at the start or in the lodge.

We also have connected the start/finish hand timing systems to a moxa so we can compute hand times in real time and EET for every racer.

There are a ton of uses for these devices and is permitted in the rules but for non-sanctioned races, the possibilities are endless. 

Also of note, the MOXA will allow up to 4 connections per port (timer), so you can use an Alge S4 with the MC-18 multi channel and time 8 courses using 4 sets of dual software/laptops or use 2 timers and each other would be the A/B system for the opposite course etc........

You asked for it so here is what we were working on. Matt saw an early non weather hardened version work successfully at a FIS race he timed.

Our objective was to create a system with recognizable homologated components that everybody was used to seeing. TAG Heuer had planned to offer the HL 450 time base for the 2021-2022 season which would have been ideal. We have used several different brands of modems for this concept but found the Raveon units to be the best packaged.

Be on the lookout for announcements from us on the upcoming debuts of several new wireless timing systems from known manufacturers that promise to exceed the FIS requirements right away without modifications. Zach is correct. There has  been a great deal of energy expended by the traditional manufacturers on wireless concepts. We have been testing the ALGE MT-1 since July with great success.  Alge Wireless MT1 (phoenix-sports.com)

Attachments

Videos (1)
TAG Heuer homologated wireless concept

There you go Zach, more ideas and a demo. I did fail to mention the new Alge MT1 that Fred has been using. As Jim pointed out, the serial device servers are an excellent solution as well. I have 4 Moxa boxes myself and use them for various ways around long distance timing.

To your question about discrepancies, in short, yes. There is the potential to have different ToD on the start timing device and the finish timing device. The difference is likely to only be thousands or tens of thousands apart. So even after net time calculation from the ToD and truncation of the result, it's rare that the net times would be different between the two timers. Yes, you do need to account for this. You need to manually or otherwise, check all the times and data. It is time consuming and if you aren't sharp, the volume of numbers is dizzying.

In the many tests that i have done, I typically bring the timing devices together, download all the data into a spreadsheet and let computing power check the differences. They are easier to identify that way, then check the tapes and validate. The same with data transmission, but there's no difference in ToD there.

Again, it is time and hardware consuming. There are a lot of moving parts. You need to have someone at least as good as you are on the other end to troubleshoot efficiently in the event of problems.

Awesome! That's a ton of cool info.



It sounds like the HL 450 isn't coming to market anymore? That's too bad, it looks like a great product. I'll have to look into the MT1.

I did look at the MOXA boxes, and would be interested to hear how you use them. Are you on the same LAN as the results computer? The internet at our starts will almost certainly be a cell hotspot, and the internet at the bottom runs through the corporate filters, so I thought making that connection might be tricky for us. I'm also self funding this project in my downtime, and the raspberry pi was more in my budget

Thanks for the replies, it's great to see how other people are doing it

Adding second timer capability opens up Split Second to many more sports. Although most of my timing efforts are in the ski racing world, I do some mountain bike DH and an auto hillclimb event. Either of those would be a good fit for a dual timer system. Good to see better minds than mine hard at work on solutions that tie it all together.

The new ALGE MT1 is a great product - propably only for a small percentage of existing timers. It has an automatic GPS sync, provides Top-of-the-minute sync to external devices, is capable of sending 2 impulse channels directly to the internet - times are stilled stored local as well. Also you can key in bib numbers which makes it perfect for individual starts.

We used it a couple of times at smaller events. Yet we are not using their online results service but using our own AlgeMt1Exchange software. This receives the impulse TOD and bib number via internet and forwards these timestamps as a traditional ALGE or Tag Heuer protocol to downstream receivers (traditional timing software like ALGE Time.NET or SplitSecond).

Add Reply

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