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