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
> > ***********
>
|