Steve,
Given the points already discussed, there are faults to the hardware side
that would be common to any timing system. For those interested in a
technical discussion of the hardware, read on.
The repeatability of the sensors to trigger consistently after the beam is
broken is a very important contributor to overall system accuracy. Every
sensor on the market today has a delay characteristic when the beam is
blocked.
Example:
A delay occurs when the beam is broken and, say, 20 milliseconds later the
signal is transmitted from the sensor to the PC or hardware timer. The
timer, in effect, starts timing 10 milliseconds later. When the car
finishes, the finish sensor must trigger with that same 20 millisecond
delay to stop the timer 10 milliseconds after the car crosses the finish
line. The net timing difference due to the sensor hardware would be zero.
If the finish sensor were to trigger at 14 milliseconds instead, the timing
hardware or software would show a time that was 6 milliseconds faster than
the car really was.
A second characteristic to consider when buying sensors is how much the
delay discussed above varies, known as the repeatability of the sensor.
The example above demostrate a 6 millisecond variation in detection, and
that's way too much. Many older photocell detectors have characteristics
similar to this example.
In order for the sensor hardware to NOT contribute to inaccuracy, the
variation of the trigger delay must be below the .001 seconds. If the
sensor triggers between a range of 20 milliseconds and 20.5 milliseconds,
the time measured will be accurate, since the .5 milliseconds is really
.0005 seconds.
This is getting deep into the technical design stuff, I hope it made sense.
Dennis Laczny
RACEAMERICA Timing Systems
http://www.raceamerica.com
>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
|