The obvious solution to the problem of sensitivity to external light is to keep the sensor (as opposed to the emitter or light source) in a dark room. This 'room' can be quite small, the principle requirement being to shade the sensor from all light except that coming from the desired source. Putting the sensor at one end of a fairly small diameter tube is a typical solution. Using IR filters are often thought of as a solution but they have minimal effectiveness simply because the offending light sources (sunlight, flash bulbs, video camera lights) have enormous IR energy. The filters help but by no means cure the problem. Putting the emitter in a 'dark room' has no benefit.
The most effective but more complex solution to the problem of sensitivity to external light is to "encode" the beam. This is a fancy word meaning the beam is pulsed, not steady. Like almost all solutions it is not without its problems. An immediate question is, "How fast does the beam pulse?" It may be helpful to consider an extreme case.
Suppose the beam pulsed one second on and one second off. Suppose a car broke the beam when it was on and the system reacted instantaneously. Now suppose a car broke the "beam" when it was off. The system could not possibly know the car was there. It would have to wait until the beam was supposed to be there and wasn't. So the reported answer could be off as much as one whole second! This would be fine if we only wanted to know if a door was closed. But it's completely useless when it comes to measuring fast racers.
Clearly the beam would have to pulse faster. In fact,
considering the pulse rate alone, the beam would have to pulse at least
twice as fast as the desired time resolution. Since racers
frequently cross the line at speeds approaching 30 mph a simple
calculation reveals that they may be traveling about 1/4" in 1
millisecond! Measuring milliseconds would seem to be adequate, but any
discrete (digital) system has a built in uncertainty of +/- 1 digit.
Put simply, when is it 12 o'clock? At 11:59? At 11:30:00.01? At 12:59?
When just 1 millisecond is reported (and that is all that is reported
by most manufacturers), then ignoring all
other possible errors (and there are several) a win is only a win if
the difference is at least 2 milliseconds. GritTimer's emitters pulse about 40,000 times per second. No
other Timer manufacturer specifies that data.
The other large error is the consistency of the sensor response time. The electronics usually used to "decode" the "encoded" beam always result in some delay between the crossing and the signal change indicating that a crossing occurred. This delay, in and of itself, is not a problem as long as it is consistent. For example, if the delay was always 1.0000 seconds then it could be safely ignored, since it would appear in all results. But the consistency of the delay is critical.
The SunX commercial IR sensors (bottle counters) sometimes used to detect racers are a good example. SunX does NOT specify their consistency (and calls to their technical support people confirmed that they do not and will not.) Instead, their specification says that the sensors will respond "within 1 mSec" of the beam being blocked. That allows the sensor to respond immediately or as much as 1mSec later and is an extremely significant additional error source since the time difference is not consistent sensor to sensor or even for the same sensor on repeated crossings. It may be better than the specification but there is no way of knowing. If it were better it's more than likely that SunX would claim the better specification.
The custom designed sensors used by GritTimer have been specifically designed to reduce the extraneous light and consistency of response problems. Shown below is an oscilloscope picture taken of the response of an actual GritTimer sensor.
You can think of an oscilloscope as an electronic graph. This is a time delay photograph of the oscilloscope that has actually recorded over 100 crossings. In this picture the dotted lines or 'boxes' represent 100 microseconds in the horizontal direction (1/10 of one millisecond.) In the vertical direction the boxes represent either 5 Volts in the top trace or 2 Volts in the bottom trace but you can safely ignore that information. The top trace is the signal being sent to and broadcast by the IR emitter. The long straight line between the pulse groups in the middle of the top trace is a "crossing". To the right of the straight line you can see that the IR beam pulses about 4 times in 100uSec. (The SunX sensor pulses about three times more slowly.) The bottom trace is the sensor output and thus measures response time. Note: A 'response' is detected by the microcontroller when the rising lower trace crosses the dots one line above the base of the lower trace. You can see that it always takes at least 180 uSec to respond and may take as much as 270 uSec to respond. Thus the "consistency" of response is less than 100 uSec, a very good value. Curiously the 'make' response is much more consistent but of no use to us. Again, no other timer manufacturer specifies their response consistency.
Now to the timer. An additional error source is the timer itself. There are generally two ways to make a timer: hardware or software. In a hardware timer the sensors connect to electronic gates, flip-flops, counters,etc. This kind of design has essentially no inherent delay, that is, it adds no potential error or so little error that it can be ignored. But it is very inflexible. It only times a heat. It can't remember anything like the previous results. It can't announce the results. And design errors or changes are expensive to implement because the circuit board usually has to be retooled and minimum order quantities purchased.
The second and more common method is to implement the timer in software. In a software design, the sensors are connected to a small computer chip (microcontroller) and all the functions are implemented thru computer code. This makes changes, result announcements, connection to race managment software and a host of features available with only modest effort. But it comes at a price. The computer can only do one thing at a time. So when it is looking for the sensor crossing, it also has to take some time to do other housekeeping tasks. Such tasks include looking for a command from the race manager software or for a push button press to end the race early or cancel a false crossing, updating the internal counters and, most importantly, recording the time of each crossing. These tasks take time. Not much time but also not a trivial amount of time. Careful programming can reduce this processing time and careful programming needs to be done. It is also obviously affected by the microcontroller operating speed. Within all models of GritTimer this processing time has been reduced to a maximum of 4 uSecs. Again, no other timer manufacturer specifies this parameter. In our experience, it's unlikely that other manufacturers even consider these error sources.
Special Note: The fairly obvious idea of using a Windows-based computer to do the actual timing will NOT work since the internal 'housekeeping' functions cannot be shut off. Such programs may report times to great precision (many places) but the inaccuracies are very large and mostly unknowable since Windows may be randomly doing 'housekeeeping' when you ask it to tell you the time. In this case the response consistency is unknowable but very large.
Combining the two error sources of response consistency and
processing time in a worst case situation for GritTimer produces a
potential uncertainty of less than 100 uSecs for any one sensor in any
one
heat. This is less than the +/- 1 digit of uncertainty in any digital
systems. Thus our recommendation with our systems is that a win of
0.0002 or less should in fairness be considered a tie at the Race
Director's discretion.