autox
[Top] [All Lists]

Re: Autocross Timing/Scoring Software

To: "Jeff Lloyd" <jslz3@hotmail.com>
Subject: Re: Autocross Timing/Scoring Software
From: "Steve Ashcraft" <ashcraft2@home.com>
Date: Thu, 30 Sep 1999 05:39:55 -0400
Jeff,
What you said would be true if the latency is the same every time. This is
the real problem. The timing heads do not respond exactly the same every
time and the computer doesn't either.  The latency in the timing head is
primarily a function of the hardware and most good timing heads have a
variability of < .0005 even though they may have a latency of >.001.  The
serious problem is the variation of the latency in the computer. This is a
factor of both the hardware (which is probably not a problem) and the
software that responds to the interrupt. I'd love to hear some opinions
about how DOS handles interrupts and if there is a problem there that is
unacceptable.
Steve

----- Original Message -----
From: Jeff Lloyd <jslz3@hotmail.com>
To: <ashcraft2@home.com>; <jacircts@mich.com>; <autox@autox.team.net>
Sent: Wednesday, September 29, 1999 10:54 PM
Subject: Re: Autocross Timing/Scoring Software


>
> but Steve the Latency Is insignificant in a timing device enviornment,
> simply the latency will effect the start and finish beams equally,
therefor
> recording the correct run time, kinda like extending your bumper 3 feet,
if
> it effects both lights equally then there is Zero Net effect on the time..
>
> YMMV
>
> Jeff
>
>
>
> >From: "Steve Ashcraft" <ashcraft2@home.com>
> >Reply-To: "Steve Ashcraft" <ashcraft2@home.com>
> >To: "John A. Carriere" <jacircts@mich.com>, <autox@autox.team.net>
> >Subject: Re: Autocross Timing/Scoring Software
> >Date: Wed, 29 Sep 1999 21:02:42 -0400
> >
> >Very good point about the latency due to how fast the operating system
> >responses to interrupts.  Does anyone know how fast DOS responds to an
> >interrupt on a serial port.  Windows is way too busy to be a viable real
> >time system.  I know that this is an open ended question since it depends
> >on
> >the serial card, what the system is doing, etc. etc. But I would like to
> >hear from anyone that has some knowledge how much latency all of these
> >things really put into the detection of an interrupt.  The real question
is
> >how much variability is there in the time that elapses from the time that
> >the external timing device sends the signal until the piece of software
> >that
> >captures the current time runs.  If the system is doing nothing but being
a
> >timer, I'd guess that variability is  pretty small but I'm probably over
> >simplifying the issue.
> >Steve
> >
> >----- Original Message -----
> >From: John A. Carriere <jacircts@mich.com>
> >To: <autox@autox.team.net>
> >Sent: Wednesday, September 29, 1999 8:38 PM
> >Subject: Re: Autocross Timing/Scoring Software
> >
> >
> > > I agree with Dennis Laczny that a PC system can not provide accurate
> > > timing.  It is a combination of the internal clock and the interrupt
> >system.
> > >
> > > In the DOS environment, the kernel can be modified to provide nearly 1
> > > microsecond precision. The accuracy over the course of a timed run is
> > > pretty good.  The Windows environment is far less timer friendly.
> > >
> > > However, it's the relatively low interrupt priority on the input ports
> >that
> > > causes the greatest innacuracy.  The PC gives the much higher priority
> >to
> > > the disk and keyboard subsystems.  If the PC timing system is using
the
> > > timing of the bus interrupts caused by the trip devices, it will
either
> > > miss some of them or have occasional inaccuracies depending on the
> >nature
> > > of the input pulse from the trip.  This is not reliable enough for a
> >system
> > > which is supposed to have 0.001 sec accuracy.
> > >
> > > If the PC system employs an input card that passes a time stamp to the
> >PC
> > > via the system bus when it receives a trip, that IS an accurate way to
> > > provide timing.  The content of the time stamp is independent of the
> >timing
> > > of the system bus communication.
> > >
> > > Someone posted earlier that the stand alone timers are computer based
> >and
> > > should have this same problem.  This is not the case because the stand
> > > alone systems employ "embedded control" microprocessors which are
> >designed
> > > to accommodate accurate timing of external control inputs.
> > >
> > > This has been a great opportunity to discuss a topic that seems to be
of
> > > broad interest.  I too would be glad to provide additional detailed
> > > background on hardware and software timing features.
> > >
> > > John Carriere
> > > JACircuits Autocross Timing Systems
> > > (734)665-3322
> > > jacircts@mich.com
> > > http://www.mich.com/~jacircts
> > >
> > >
> > > Dennis Wrote:
> > > >
> > > >John's point of having to reset the PC time-of-day is right on.  A PC
> >is
> > > >driven by an interrupt system and the I/O ports where sensors are
> >connected
> > > >and the internal time-of-day clock are the lowest priorities due to
the
> > > >slow data rates (compared to what is going on inside the PC at 200Mhz
> >+)
> > > >and this lower priority causes the time-of-day clock (and the .001
> >second
> > > >requirement) to vary slightly.
> > > >
> > > >All of the software timing solutions are cost effective (if you don't
> >count
> > > >the cost of the PC) and offer the driver registration and scoring,
some
> > > >offer the timing also.  Software timing will vary slightly from one
PC
> >to
> > > >another based on what's in the PC, so comparing results from one
region
> >to
> > > >another would not be accurate to .001 seconds.  Comparing results
from
> >one
> > > >event to another would require using the same PC hardware for both
> >events,
> > > >but even then, that would not guarantee .001 second accuracy for both
> > > >events.
> > > >
> > > >Hardware timers have accuracy far beyond the .001 seconds.  Comparing
> > > >timing results from one event to another or one region to another
would
> >be
> > > >completely accurate irregardless of which hardware timer was used
(okay
> > > >there are some really old timers that would be excluded).
> > > >
> > > >- --- I meant 'timers that are old' and not 'old-timers', okay ---
> > > >
> > > >Most hardware timers and most software packages interface to large
> >displays
> > > >to display race results.  The only difference here is what
information
> >can
> > > >be displayed, that varies with the display as well as the
> >hardware/software
> > > >used to score.
> > > >
> > > >Cost is always a factor in timing equipment.  Redundancy should be
> > > >considered just as important, after all, when the automated timing
goes
> > > >away ... it's back to stopwatches.
> > > >
> > > >I would be glad to provide additional detailed background on hardware
> >and
> > > >software timing features and advantages.  If you are interested, give
> >me
> >a
> > > >call at (408) 988-6188 or reply back with a phone number and I will
> >give
> > > >you a call.
> > > >
> > > >
> > > >Dennis Laczny
> > > >RACEAMERICA Timing Systems
> > > >http://www.raceamerica.com
> > > >
> > >
> > > JACircuits Autocross Timing Systems
> > >     http://www.mich.com/~jacircts
> > > - Timing the SCCA Solo II Nationals since 1985
> > > ***********
> >
>


<Prev in Thread] Current Thread [Next in Thread>