Skip to main content

To be adopted in November:

Art. 611.3.5

Computer software calculating net times must use the precision of the time of day as used in the timing device.



Therefore if the timer outputs 10,000ths of a second the software must subtract the finish from the start at 10,000ths, then truncate the net to 100ths. Different timers have different outputs. ALGE TDC 800x , and TIMY timers output 10,000ths, S4, S3 and Comets output 1,000ths.

Make sure you check the calculations that your software is performing. The net time generated by the software and by subtracting the times off the timer printer must be exactly the same.

Make sure that you have the correct timer selected if they don't match. Like a TAG PTB ver 3 instead of the original PTB.
Original Post

Replies sorted oldest to newest

The rule states that timing software must use the full precision that is offered by the timing device. A typical time stamp from a ptb to the software can look something like this (you can find this view of the data in the RAW DATA box in setup and test from SST or from using the PTB Controller program).

T 00005 01 08:44:17.827998
Channel 1 is a start channel

T 00001 02 08:45:32.127026
Channel 2 is a finish

Calculated Net time is

08:45:32.127026
08:44:17.827998
---------------
1:14.299028

Truncate to the 1/100th and a net of 1:14.29 is generated

Now what happens if you use what is printed on the tape to the .001 precision (default setting)

08:45:32.127
08:44:17.827
---------------
1:14.300

Net time is now 1:14.30

Next a printed tape to the 1/10,000 precision

08:45:32.1270
08:44:17.8279
-------------
1:14.2999

Truncated Net time is back to 1:14.29

And finally what is happening with the software. The software can see the full precision from the PTB to the 1/500,000 precision and from an email from Geoff it is reported to use the full precision however you cant see it. Because the default print setting of the PTB is 1/1,000 Geoff has set all timing logs and time of day edit views show only the 1/1,000 precision and MAY look something like

St 8:44:17.827000 bib 5 run 1
Fin 8:45:32.127000 bib 5 run 1

Looking at the full precision (which is hard to see) the net calc is 1:14.29. Looking at the 1/1,000 precision that is shown the net calc is 1:14.30. I did email Geoff about this and he is refering to his FIS representitive for clarificaiton on this timing device and how to represent the data.

How does this difference of 1/100 of a second affect results? Even if it doesn't cause a tie it will change race points and possibly the penalty. Can you see it from looking at the tape? Not unless you can print to the full precision of the time base or at least to the .0001 precision in some cases.

The PTB does not offer printing to the full precision that is offered by the time base and I susspect that the 705 and the new 606 do not either. If it was you would see six digits after the decimal point for their claimed 1/250,000 precision. From what I see this is actually expressed as 1/500,000 precision as the last digit is always even. This will in some cases affect the calculated net time.
Last edited by john
John,

Thanks for the explanation on this.

I've sent a list of all supported timers in Split Second Software and the precision I use for each, asking if it's correct.
The wording of this rule opens the door for interpretation, so no matter what side is taken, it could be 'wrong'. If I need to make any changes it will be very simple to do...

I'll post the outcome as soon as I receive a reply.
Here's is the reply that Ted kindly sent:

>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>

Hello Geoff:

Thanks for your note. Yes, we are exceedingly busy with the approach of the
Lake Louise Alpine WC events, all of the Alpine WC events in AUT and of
course with our recent take-over of the Kitzbuhel contract now representing
ROLEX. The recent cancellation of the opening Soelden World Cup was the
only break in an otherwise nut-case month. The Updates are always a
challenge.

I'm copying a wide range of interested parties because the points you raise
are important and quite specific to CAN/USA.

611.3.5 is in there to respond to the observed reality. The FIS does not
homologate downstream software (despite many requests to do such a thing to
clean up the mistakes out there worldwide). I doubt if this is a concern of
yours since whatever issues that did exists with the TAG systems and Split
Second were solved years ago and you are wise to this trap. Not so for
everyone out there in the FIS world and thus the concern/remedy. There are
also some other pertinent concerns.

The FIS only homologates and looks at data from FIS races based on
homologated timing equipment and what comes out of the timer printers. What
happens downstream from the timers involved is the entire responsibility of
the ROC, and one would suppose, the software authors that host those
systems. Our FIS Timing Working Group is of the opinion that whatever
happens downstream of the timing systems is really none of our business and
we should not get involved in controlling the creative process. The FIS has
also recently struck a FIS Data Working Group and they may elect to police
such matters in the future if things continue to get out of hand. Not my
purview.

The current rules clarify this position and reinforce the need for
downstream systems to be in sync with what each homologated timing device
it may be connected to actually prints.

Things the FIS would like to avoid (and thus the appearance of this rule):
- Timer precision on the timer tapes that does not precisely match
the methodology used by downstream systems or devices. (Ex: Printer tapes
prints TOD in 1/1000ths, Software uses TOD in 1/10,000 - results often
different by .01 when calculated).
- Mistakes in calculations relative to what appears on homologated
timer printer tapes when compared to calculations in TOD produced by
downstream software. (Almost the same as above but perhaps the truncation
method is incorrect)
- The assumption by timing operators that downstream software super
cedes the necessity of always referring back to and checking time data
relative to the FIS homologated timers in use and based on what shows up on
the timer tapes.
- The omission by many ROCs to treat the homologated timer tapes as
the only correct source of recorded data. (Software memory or software
printer records are not acceptable evidence of what was produced by the
homologated timer.)

As to your list of devices, I would concur that your list is correct
relative to the ALGE and TAG systems you noted. I cannot comment on the
accuracy of the device characteristics from other manufacturers you show
there. I would strongly urge you however to contact ALGE and TAG Heuer
directly for a definitive statement of compliance.

I would further suggest that the USA agents for these devices (Absolute
Precision, Phoenix, or Reliable Racing) would be glad to supply you with
timers to test your compliance with their specific models without charge.
This is what I do in Canada for all software authors in all sports.

As for the FIS TD Updates that I conduct with my USA counterpart, topics of
discussion and instruction that touch on timing and results are many.
Thelma Hoessler, Allen Church and myself covered a wide rang of topics from
timing, reporting on the forms, noted errors from last season, live-timing
challenges (obvious mistakes that get posted), live-timing options (4 new
methods that have appeared in 06-07) and xml transmission to FIS and how to
check the outbound files. Nothing specific to Split Second or any other
author or timing manufacturer was mentioned in detail. Do you have any
specific concerns that I can address or refer to others?

A few race software authors from Canada traveled to the Update in Seattle,
and I see that some others will be in Ottawa next week. You are of course
welcome to enhance our meetings by attending and contributing. We also have
vendor tables available at a minimal charge (Paul Van Slyke can handle that
for you).

If I may offer some constructive advice:

Many of your software competitors allow for the use of stand-alone timing
systems operating in Net time to provide net-time-only data (bib # + run
time) to the downstream software. To our knowledge SS does not do this yet.

There is no TOD transfer nor downstream time calculation being done in this
case where net times are used from the homologated timer. These software
systems may also permit the valuable enhanced operation of many
intermediates, speed traps, Live-Timing and other features that a
stand-alone homologated timing device just does not deal with well - but
without the risk of using a PC as the only device that calculates the
run-times from TOD data. I believe that you have looked at noted problems
when 705, TIMY and 800x operators send TOD+Net to Split Second and have
corrected those problems.

In Canada we have seen a strong return to the use of stand-alone
homologated timing systems (8001's / 705s / 520s / TIMYs) and yet your
software does not seem to allow these systems to directly drive your
software on-line in net time mode (you only key off TOD and recalculate
what has already been provided). Can this be changed or added as a valuable
option? I have discussed this at length with Julie Lemieux at ACA since it
impacts the viability of how any Live Timing solutions may be approached in
Canada.

Reach me at any time with your comments by Email or phone and accept my
best regards for a successful new season.

Sincerely,

Ted Savage
Member, FIS Timing Working Group
FIS TD Commissioner for CANADA
President, Precision Timing International Inc.
Chief Technology Officer, Clarus Networks Inc.

514.606.8463 MTL mobile (CAN)
646.546.6451 NYC mobile (USA/EUR)
>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>


Ted,

Hope all is well, and you're keeping busy enough...

I just wanted to check I'm interpreting the new FIS rule correctly:

"611.3.5 Computer software calculating net times must use the precision of
the time of day as used in the timing device."

It sounds straightforward but for a couple reasons there's potential for
confusion. Please let me know if the following are correct:
Timer Precision

ALGE TdC 8000/8001 1/10,000 (4 digits)
ALGE TIMY 1/10,000 (4 digits)
ALGE S4 1/1,000 (3 digits)
ALGE Comet 1/1,000 (3 digits)
ALGE S3 1/1,000 (3 digits)
ALGE TdC 4000 1/1,000 (3 digits)
TAG Heuer CP 705 1/1,000* (3 digits)
TAG Heuer CP 520 1/1,000* (3 digits)
TAG Heuer PTB 605 1/1,000* (3 digits)
TAG Heuer 650 Splitmaster 1/1,000 (3 digits)
TAG Heuer 502 1/1,000 (3 digits)
TAG Heuer 503 1/1,000 (3 digits)
TAG Heuer 505 1/1,000 (3 digits)
Summit Systems SRT 1000 1/1,000 (3 digits)
Microgate RaceTime 2 1/1,000 (3 digits)
Microgate REI2 1/1,000 (3 digits)
OMEGA TL5005 1/1,000 (3 digits)

* The TAG Heuer PTB 605 sends data to the computer in 1/1,000,000 (6
digits) (although I guess it's 1/500,000?). I had been using this full
precision but was told I should use 1/1,000 since that 's all that prints
directly on the device's printer, and so that's all that could be verified.

I'm hoping I have all these correct. I don't have all these timers and so I
thought it best to check with you. Please let me know of any changes I
should make.

Also, I noticed there were items on the FIS meeting agenda that may have
concerned me. Could you let me know anything I should be aware of regarding
those?

I look forward to your reply.

Regards,

Geoff Elder
So it seems that the wording of the FIS rule should be more like.

Computer software calculating net times must use the precision of the time of day as used in the timing device calculations OR DEFAULT PRINTING IF THE DEVICE DOES NOT PROVIDE FOR INTERNAL CALCULATIONS.

I personally enjoy the many features of SST that would not be possible if only NET times were used.
quote:
I personally enjoy the many features of SST that would not be possible if only NET times were used.


As much as possible, without interfering with the functionality of the software, I try to make it all things for all people. I know there are a lot of users in Canada with the 8000 plus, and if they prefer to use it with Net times, it's understandable given the investment.
So, I'll see what I can do to add some functionality to receive net times too. The software already does this for the 4000 since that all it sends out, but with the 8000 it will have to be in a different way.
The software will already receive times from the TDC 4000, TDC 8000/8001, and the TIMY. The selection of TDC 4000 in the Setup and Test will force the software to look for net times and bibs coming from the timer. All of the ALGE timers have exactly the same "scoreboard" output.

The TIMY is run in "STOPWATCH" mode and the data output for the software is either taken from the banana plug output or the DB25. The TIMY is run in single run mode for both. It creates net times and sends them to the SST. The SST adds the two runs together normally, displays them to scoreboards, etc. You cannot run the TIMY in two run mode right now as the SST will accept the Total Time instead of the 2nd run time for calculations. You have to be quick at accepting the time since the TIMY does not have a "running time" or "standing" selection and wants to keep sending the net time over and over again which will lead to a buffer overload.

The TDC 8000/8001's shipped from PST have always had a dual cable harness. The Blue side has been marked as a direct TOD RS232 interface for the SST in TDC 8000/8001 mode. The Green side is marked as a TDC 4000 for those customers that wanted to do ALL of their timing on the 8000/8001. You have to make sure that the menu selection #20 for D-board Channel 2 = STANDING is selected. Then connect the data cable as labled. You can see the running time coming in to "setup and test" "show raw times" if it is selected wrong or the plug is in upside down. This has been working successfully for these customers for years.

And yes, the ALGE TDC 4000 is still a great timer and is quite useful.

One final note. ALGE scoreboard output is limited to 3 digit bibs. Any thing over 999 is not recognized by the software.
Last edited by fkp

Add Reply

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