Tweet
To verify that my new one of a kind lap counter made using optical sensors, a Phidget 16 channel digital input/output card and the Slottrak Race Management System worked properly I decided to put it through my test program. I have done this test many times on both optical and dead strip type lap counters. A lap counter that passes these tests will never give you a problem. The following draft was prepared for my Siberia Racing Tech Pages section. A new page will be up there soon on how I test lap counters. In the meantime enjoy the following preview. This post is a continuation of a discussion in The Paddock titled “Lap Counting: Dead Strips, Light Bridges, Other.
TESTING LAP COUNTERS
The physical installation and configuration of a lap counter is just the first step of a multi-step process. Unless the entire lap counter system is rigorously tested there is no assurance that it will work in all instances. For example, at a HOPRA national event the super stock track’s lap counter failed during the main when cars started going over the counter faster than the counter could detect them. This problem was undetected during qualifying or the semis. It only happened in the main. Fortunately it was caught early in the race and the marshals kept the race director informed when cars missed a lap.
The above isn’t the only case I have personally experienced. It is one of many. In my 50+ years of experience racing slot cars of various scales I have seen almost every type of lap counter system fail. I have also seen them operate successfully. I will go over methods to test optical and dead strip lap counters. In my opinion lap counters that use items such as hall-effect sensors and reed switches cannot be reliably tested.
The above HOPRA national’s failure was caused by a channel update time issue. Every lap counter system (mechanical or electrical) has a minimum time that the car must be over the sensor before the counter will detect and count it. Depending on the circuits physical and electrical characteristics, this time can range from microseconds to milliseconds.
A millisecond is 1/1,000 of a second. A response time of several milliseconds sound fast. It really isn’t when you are dealing with three inch long cars traveling at an average speed of 20 feet (240 inches) per second. Assuming that an optical detector is being used, the time that a three inch long car traveling at 20 fps spends over the sensor is 3/240 = 0.0125 seconds or 12.5 milliseconds. When you consider that the fastest average speed for a HO scale race distance (including gutter lanes and corners) is over 40 feet (480 inches) per second, a millisecond is not long at all.
Windows or other clear spaces in the body can also adversely impact the systems detection time. At one race we had to paint the front and rear windows to get cars to reliably count when they passed over the optical sensor. Dead strip tracks have had similar issues due to differences in pickups, pickup tension or pickup bounce.
The only reliable way I know of to test a lap counter system is to pass a car over the lap counter at a speed that is several times faster than the fastest cars you plan on racing. Remember that straight line speed is greater than average lap speed. Depending on the lap counters location, a car having an average speed of 16 Feet Per Second (FPS) over a lap could be significantly faster (20 fps or more) when it crosses the lap counter.
There are two types of time issues that we are trying to guard against. The first is the single channel update time. In other words how much time is required for a single channel to detect a car crossing the sensor. This is the only issue of concern if the track uses individual counter modules for each lane such as the tracks mentioned above. This is great for lap counters that use individual electrical circuits for each lane. Unfortunately the days of the TCP or the TrixTrax counter have past. The modern computer driven Race Management Systems (RMS) use an interface card that receives inputs from multiple sensors. This is true of systems that use an interface card and systems in which the sensors are connected directly to a serial or parallel port.
What we are concerned with and RMS system is not only the time for a single channel to detect the car but also how often is the RMS looking at that channel and how often does the interface card report that channels status. If the RMS spends a millisecond looking at each channel it would take a minimum of 4 x 1 = 4 milliseconds to scan the sensors on a four lane track. However, if the interface card spends an additional 2 milliseconds to report the status of each sensor in sequence this could add an additional 4 x 2 = 8 milliseconds to the time necessary to scan all four sensors. The total update time could be 12 milliseconds or more. If the car only spends 12.5 milliseconds going over the detector then there is almost no margin for error.
Unfortunately the problem is not the number of lanes on the track. The problem is the number of channels on the interface card. If the interface card has eight input channels, the time to scan all of the inputs and report the data to the RMS could be 3 x 8 = 24 milliseconds and the counter would not be reliable.
The scan rate was the problem on my latest lap counter design that used the Slottrak RMS and a single Phidget 0/16/16 card for all I/O functions. Each Phidget channel had a minimum detection time of 0.004 seconds. This is one third of 12.5 milliseconds and detection shouldn’t be a problem. The problem was that when all three lanes were tested simultaneously, one lane would not count because of the cards 16 input channels. Scanning rate data is not published. I used the brute force approach and solved the problem by adding a 0.4 second time delay circuit. Each lane has its own time delay circuit located between the sensor and the interface card. Each time delay circuit has an activation time of a few microseconds (1/1,000,000 of a second). When activated, by a car blocking the optical sensor, the time delay circuit holds the interface channel input high for approximately 0.4 seconds. This solved the problem. A delay time of 0.4 seconds was chosen as it is less than the programs 0.5 second default minimum lap time. As the delay was less than the default minimum lap time the time delay circuit would be operating in the background and could not interfere with the lap counter’s function in any way.
For a dead strip installation, the system is tested by taping over the dead strip rails until the lap counter becomes unreliable. I would start by taping half of the length over. I probably would start taping from the end of the dead strip working toward the beginning of the dead strip to check if pickup bounce was causing a problem. I would then run the fastest car over the counter for a minimum of 20 laps. Twenty qualifying laps are hard to string together which is why I chose 20 laps. If all laps are detected, I consider the system to be reliable. I would then repeat the test with more and more of the dead strip taped over until the system became unreliable. The last successful test provides the minimum update time (or distance) required for the system to operate.
With a dead strip one thing to look for is the transition from the track rails to the dead strip section rails. You don’t want the pickups to bounce excessively over this transition as this can lead to counting issues. Pickups in the air do not provide an input signal to the lap counter. Likewise, bouncing pickups shorten the signal that is provided to the lap counter.
Unfortunately this method tests only one lane of a dead strip system at a time. To ensure that there are no scanning issues you need to test all of the lanes simultaneously. This is almost impossible to do with a dead strip system without adding an external circuit that triggers all lanes simultaneously. I haven’t used a dead strip for at least 20 years and have not had to build such a circuit. If I did I would probably use a 555 chip to send a signal with a definitive time to all lanes simultaneously. You then would work backwards to calculate how long the dead strip would be to provide a signal with the same time duration as the simulated signal.
It is possible to quickly test all lanes simultaneously on a track that uses optical sensors. When testing a track with optical sensors I equip a test car with “wings” that trigger the lanes adjacent to the lane the car is running in. The test car for my current three lane track is shown below.
The test car is a HOPRA ceramic super stock car with a Lexan body fitted. Tires are silicone on sponge. The car has finished in the top three in several races so it’s not a stone. The wings on the test car are made from folded and cut up post-it notes and are approximately one fifth of an inch long. The car body is approximately 2.5 inches long. The car was driven as fast as possible for 23 laps. The lap counter was declared acceptable as all of the lanes simultaneously triggered by the car indicated the same number of laps. I have tested four lane tracks using a similar system. My assumption is that a suitable rig could be made to test a six lane track as well.
What I am looking for with these lap counter system tests is how much of a time (or distance) difference do I have between the time required for the car to pass through the detector and the last successful test. For example with my winged test car I have a safety factor of five as the wings are one fifth as long as the entire car. With a dead strip that operates successfully with 80% of the rail taped off the safety factor would be five as well. I want my lap counter systems to have a minimum safety factor of three or higher when all lanes are triggered simultaneously.
What about tracks that use other detection methods such as hall-effect sensors or reed switches? There really is no way to determine how much of a safety factor these systems have as they either work or they don’t. There is no way to tape off or trick the sensor to determine if it would count a faster car. I have seen enough of reed switch systems fail that I don’t consider them reliable. I have only seen one track that used a hall-effect sensor. It seemed fine but then again I was the only car on the track. As with reed switch systems I would be concerned with the car on an adjacent lane causing interference and false counts.
TESTING LAP COUNTERS
The physical installation and configuration of a lap counter is just the first step of a multi-step process. Unless the entire lap counter system is rigorously tested there is no assurance that it will work in all instances. For example, at a HOPRA national event the super stock track’s lap counter failed during the main when cars started going over the counter faster than the counter could detect them. This problem was undetected during qualifying or the semis. It only happened in the main. Fortunately it was caught early in the race and the marshals kept the race director informed when cars missed a lap.
The above isn’t the only case I have personally experienced. It is one of many. In my 50+ years of experience racing slot cars of various scales I have seen almost every type of lap counter system fail. I have also seen them operate successfully. I will go over methods to test optical and dead strip lap counters. In my opinion lap counters that use items such as hall-effect sensors and reed switches cannot be reliably tested.
The above HOPRA national’s failure was caused by a channel update time issue. Every lap counter system (mechanical or electrical) has a minimum time that the car must be over the sensor before the counter will detect and count it. Depending on the circuits physical and electrical characteristics, this time can range from microseconds to milliseconds.
A millisecond is 1/1,000 of a second. A response time of several milliseconds sound fast. It really isn’t when you are dealing with three inch long cars traveling at an average speed of 20 feet (240 inches) per second. Assuming that an optical detector is being used, the time that a three inch long car traveling at 20 fps spends over the sensor is 3/240 = 0.0125 seconds or 12.5 milliseconds. When you consider that the fastest average speed for a HO scale race distance (including gutter lanes and corners) is over 40 feet (480 inches) per second, a millisecond is not long at all.
Windows or other clear spaces in the body can also adversely impact the systems detection time. At one race we had to paint the front and rear windows to get cars to reliably count when they passed over the optical sensor. Dead strip tracks have had similar issues due to differences in pickups, pickup tension or pickup bounce.
The only reliable way I know of to test a lap counter system is to pass a car over the lap counter at a speed that is several times faster than the fastest cars you plan on racing. Remember that straight line speed is greater than average lap speed. Depending on the lap counters location, a car having an average speed of 16 Feet Per Second (FPS) over a lap could be significantly faster (20 fps or more) when it crosses the lap counter.
There are two types of time issues that we are trying to guard against. The first is the single channel update time. In other words how much time is required for a single channel to detect a car crossing the sensor. This is the only issue of concern if the track uses individual counter modules for each lane such as the tracks mentioned above. This is great for lap counters that use individual electrical circuits for each lane. Unfortunately the days of the TCP or the TrixTrax counter have past. The modern computer driven Race Management Systems (RMS) use an interface card that receives inputs from multiple sensors. This is true of systems that use an interface card and systems in which the sensors are connected directly to a serial or parallel port.
What we are concerned with and RMS system is not only the time for a single channel to detect the car but also how often is the RMS looking at that channel and how often does the interface card report that channels status. If the RMS spends a millisecond looking at each channel it would take a minimum of 4 x 1 = 4 milliseconds to scan the sensors on a four lane track. However, if the interface card spends an additional 2 milliseconds to report the status of each sensor in sequence this could add an additional 4 x 2 = 8 milliseconds to the time necessary to scan all four sensors. The total update time could be 12 milliseconds or more. If the car only spends 12.5 milliseconds going over the detector then there is almost no margin for error.
Unfortunately the problem is not the number of lanes on the track. The problem is the number of channels on the interface card. If the interface card has eight input channels, the time to scan all of the inputs and report the data to the RMS could be 3 x 8 = 24 milliseconds and the counter would not be reliable.
The scan rate was the problem on my latest lap counter design that used the Slottrak RMS and a single Phidget 0/16/16 card for all I/O functions. Each Phidget channel had a minimum detection time of 0.004 seconds. This is one third of 12.5 milliseconds and detection shouldn’t be a problem. The problem was that when all three lanes were tested simultaneously, one lane would not count because of the cards 16 input channels. Scanning rate data is not published. I used the brute force approach and solved the problem by adding a 0.4 second time delay circuit. Each lane has its own time delay circuit located between the sensor and the interface card. Each time delay circuit has an activation time of a few microseconds (1/1,000,000 of a second). When activated, by a car blocking the optical sensor, the time delay circuit holds the interface channel input high for approximately 0.4 seconds. This solved the problem. A delay time of 0.4 seconds was chosen as it is less than the programs 0.5 second default minimum lap time. As the delay was less than the default minimum lap time the time delay circuit would be operating in the background and could not interfere with the lap counter’s function in any way.
For a dead strip installation, the system is tested by taping over the dead strip rails until the lap counter becomes unreliable. I would start by taping half of the length over. I probably would start taping from the end of the dead strip working toward the beginning of the dead strip to check if pickup bounce was causing a problem. I would then run the fastest car over the counter for a minimum of 20 laps. Twenty qualifying laps are hard to string together which is why I chose 20 laps. If all laps are detected, I consider the system to be reliable. I would then repeat the test with more and more of the dead strip taped over until the system became unreliable. The last successful test provides the minimum update time (or distance) required for the system to operate.
With a dead strip one thing to look for is the transition from the track rails to the dead strip section rails. You don’t want the pickups to bounce excessively over this transition as this can lead to counting issues. Pickups in the air do not provide an input signal to the lap counter. Likewise, bouncing pickups shorten the signal that is provided to the lap counter.
Unfortunately this method tests only one lane of a dead strip system at a time. To ensure that there are no scanning issues you need to test all of the lanes simultaneously. This is almost impossible to do with a dead strip system without adding an external circuit that triggers all lanes simultaneously. I haven’t used a dead strip for at least 20 years and have not had to build such a circuit. If I did I would probably use a 555 chip to send a signal with a definitive time to all lanes simultaneously. You then would work backwards to calculate how long the dead strip would be to provide a signal with the same time duration as the simulated signal.
It is possible to quickly test all lanes simultaneously on a track that uses optical sensors. When testing a track with optical sensors I equip a test car with “wings” that trigger the lanes adjacent to the lane the car is running in. The test car for my current three lane track is shown below.
The test car is a HOPRA ceramic super stock car with a Lexan body fitted. Tires are silicone on sponge. The car has finished in the top three in several races so it’s not a stone. The wings on the test car are made from folded and cut up post-it notes and are approximately one fifth of an inch long. The car body is approximately 2.5 inches long. The car was driven as fast as possible for 23 laps. The lap counter was declared acceptable as all of the lanes simultaneously triggered by the car indicated the same number of laps. I have tested four lane tracks using a similar system. My assumption is that a suitable rig could be made to test a six lane track as well.
What I am looking for with these lap counter system tests is how much of a time (or distance) difference do I have between the time required for the car to pass through the detector and the last successful test. For example with my winged test car I have a safety factor of five as the wings are one fifth as long as the entire car. With a dead strip that operates successfully with 80% of the rail taped off the safety factor would be five as well. I want my lap counter systems to have a minimum safety factor of three or higher when all lanes are triggered simultaneously.
What about tracks that use other detection methods such as hall-effect sensors or reed switches? There really is no way to determine how much of a safety factor these systems have as they either work or they don’t. There is no way to tape off or trick the sensor to determine if it would count a faster car. I have seen enough of reed switch systems fail that I don’t consider them reliable. I have only seen one track that used a hall-effect sensor. It seemed fine but then again I was the only car on the track. As with reed switch systems I would be concerned with the car on an adjacent lane causing interference and false counts.
Comment