For our series on race timing, we’re taking a look at a popular infrared detector, the I-Lap Race Timing System. The I-Lap timing system was one of the first systems adapted for drone racing, but is still essentially an R/C car setup turned on its side.
If you haven’t yet read our Lap Timing Guide, you will probably want to check that out before reading this article. That guide covers the basics of lap timing and the various types of systems available, while this one is specific to the I-Lap product.
Like most IR timers, the I-Lap system consists of a set of sensors, sensor cables, a decoder unit, a long decoder cable, and a USB cable. The 6 sensors in our kit easily cover the entire area that we would like to measure. Sensors connect together with standard RJ45 network cables, making the cables easy to replace if they are damaged. From the last sensor, a 50-foot cable is included that connects to the decoder block. This generous length really helps us keep our setup and equipment a safe distance away from the race course. The decoder block is shrink sealed so it’s not a problem leaving it on the ground outdoors. The system is not inexpensive. Our detector kit cost $380 ($140 for the decoder plus $40 each for 6 sensors).
Each quad needs to have an IR transmitter installed which passes a unique ID code to the detectors. The I-Lap transmitters are fairly small and light. 3S and 4S quads will not notice the added weight, but most 1S and 2S micros would have a noted—and probably prohibitive—performance difference. Each requires 5V and has a servo connector attached. This isn’t as commonly available as it once was—with 4-in-1 ESCs in widespread use and more FCs having integrated PDBs, many builds now don’t use servo connectors at all. If you don’t want to solder the IR transmitter directly, you may be installing pin headers just to use it. Each transmitter is about $40, which we feel is a ridiculously excessive price, especially considering some of the transmitters we received were wired backwards. There are some DIY solutions which can be built for as little as $3 each, but of course, these are not guaranteed to be fully compatible.
The system arrived as bare components. For it to function, sensors need aligned across one side of the start/finish line, so we had to construct something to hold the sensors. While the sensors are all shrink wrapped and appear reasonably durable, we didn’t want to leave things to chance with any high-speed collisions with race quads. Our solution was to construct a scaffold from PVC piping. I threaded the sensors inside a length of pipe and cut windows at regular intervals. The scaffold is free-standing so we can set it up at any location using any kind of gate. Our scaffold also shields the detectors from sunlight, because they don’t work as well otherwise. Our group probably spent another $20 and a few hours constructing this timing pole, but it was a worthwhile investment: more than once the hard shell has protected our sensors from a direct hit.
Installing a transmitter can be a challenge. It must be set so that the IR LED points toward the detectors when the quad passes by. It’s also important that nothing (including spinning props) pass between the LED and detectors. This, too, is not being helped by trends in frame design of smaller plates and fewer orthogonal surfaces. It’s almost impossible find an open space that meets all of these requirements on some quads. Because there’s so much to watch out for, it’s necessary to scan each user’s quad through the system before the event to make sure it works.
I-Lap recommends the sensors are installed vertically, and transponders point off to the side of the quad. There’s some sense in this; quads often fly with a lot of forward tilt and recording from the side negates the effect on the IR emitter. When sensors are installed above or below the gate, forward tilt on the quad reduces the beam’s strength and changes where in space the quad is picked up. This does add yet another thing to check for during setup; everyone needs to know which side their emitter should point to.
To connect to your computer, drivers for the decoder are included on a USB drive. The drive also comes with a copy of Laps Free, Flipside Racing, and a light version of RC Scoring Pro.
At each event, our pre-race setup requires time to construct the scaffold, hook up and protect the wiring, connect the computer, get it powered, and test that it all works. We also have to add time to check in each racer’s ID code and figure out what’s wrong when they aren’t working. It definitely extends the setup period by a significant amount. After all of this setup is done, everything else to run the event is done in the software—as long as you don’t find that you’ve set something up incorrectly. The system is ready to track your heats all day, and the number of racers you can have in each heat is basically unlimited.
Our I-Lap system came packaged with 3 different applications, though they maintain a list on their site of many more. We settled on FlipSide Racing as the right choice for our group for a few important reasons, mostly hardware related. We wanted a program that could run on each of the systems we would be likely to have, which include macs and a netbook. A surprisingly large number of these programs can’t handle screens smaller than 1024×768. FlipSide is actually a bit of a stretch, too; but it’s usable. However, FlipSide may have been our choice anyway—it has a good feature set without becoming overly complicated. Another bonus: it’s free. After spending hundreds just for the hardware, it can be hard to swallow another large software purchase. FlipSide is open source, but requires a proprietary commercial compiler to modify.
Connecting the equipment, loading drivers, and testing that the system works is always the first step. Once that’s taken care of, an event organizer will need to enter racers into the database and set up the race profiles. There are only a few required fields in FlipSide: unique identifier (UID), name, and whether a racer is ‘enabled’. If you have the transmitter nearby and powered, you can create a new racer and press “Scan”. This activates the detectors and returns the first ID code it finds. You can use this to quickly assign the UID code to a racer without risking a typo on manual entry.
The “Enabled” field tells FlipSide that it is allowed to record times for this racer. If you don’t have a racer enabled, they will never show times even if the IR system detects them. Your racers can share IDs in the database, but only one of any given UID can be enabled at one time. This allows you to enter pilots in the database with a dummy ID before the event and scan in their codes when they arrive. It also allows racers to physically share a transmitter, as long as you remember to switch the enabled flag when appropriate. The “Scan” feature and the enabled checkbox sometimes act non-intuitively, so they must be watched closely. For example, if you scan a transmitter while creating a racer but another racer already has the scanned ID, FlipSide will switch you to editing this other racer instead of adding the scanned ID to the new one.
You can add or remove other data fields. We use one to keep track of who owns their transmitter. (The above behavior means it’s best to clear the ID field between events for any racer who rents one, but we don’t clear out those that stay constant.)
Your software setup also includes race settings. These are not always fully explained, but we didn’t find them difficult to figure out. For example, the “Time Limit” is expressed in minutes, but the “Minimum Lap time” is in seconds—neither have units showing on the interface. FlipSide offers a “Staggered Time” race type, which means that each racer begins timing their own race when they reach the start line for the first time. This frees us from using the PC to begin the race. As long as the timer is running, we can call the start whenever all are ready and not have another person manning the PC to begin every race. We also don’t need to amplify the tiny laptop speakers through a sound system.
Many software packages want to set up heats for you. This can be nice if you use the structure the developer likes, but it can also get in the way if it’s enforced or you need to make changes in the middle of an event. With FlipSide, there’s nothing to set up here. Simply begin your race. Flipside watches the course and adds each racer it sees. When a racer passes a second time, it records a lap. This means that we have to organize our own heat structure. Other software will aggregate event data for you which can be nice and definitely saves on bookkeeping, but we like the flexibility to define our own structures and change up the heats on the fly.
Every race time is stored in FlipSide’s database, so they can be reviewed later. This is a simple thing with huge benefits. For one, while you are racing you can ignore the bookkeeping altogether. When a race is over, you can start a new one right away—just go back later to get results from the earlier race. This allows you to start races as quickly as pilots can get ready for the next heat and really keeps the event moving along at a good pace.
The history viewer allows you to print reports like total times and individual lap times for each racer, best lap, how many laps each racer lead, and so on. It also offers graphs to help visualize the data. One oddity we found is that the history viewer won’t ever consider the first lap as the “best” lap when it displays the grid. If you’re doing a prize for best lap, you’ll have to check each racer manually. It’s a pretty efficient system, but doesn’t offer any aggregation. To determine event standings across multiple heats, you’ll need to manually record and compare elsewhere.
The I-Lap timing system with FlipSide offers precise timing and a lot of flexibility, but it comes at a pretty heavy cost in time and materials. Setup takes a long time and requires a lot of equipment. We’ve continually had issues with reliably getting transmitters to register when they cross the line. This might be the transmitter wasn’t powered on, was pointed the wrong way, or because something got in between; it might be because the sun reflecting off something made the detector stop working or the quad passed to close or too far away from the detector; it might be because the pilot flew through the start gate at a bad angle; or it might be because the pilot wasn’t enabled in the software, the minimum lap time was set incorrectly, or the race didn’t start properly. There are so many ways the timing might go wrong. It was always a guess whether we would get times for each pilot at all. Transmitters are expensive and difficult to install. The system seems at home in the RC car environment, but less suited to timing quads.
To be fair, though, if the I-Lap is set up correctly in all respects (system, software, and pilot transmitters,) it registers times precisely and accurately. Once set up, it’s capable of running an event with great speed and efficiency. IR setups have a distinct advantage over VTx-based systems when it comes to managing the data that’s collected at an event because of the unique IDs assigned to each racer. It’s a reasonably good system that fills a need, and as of this writing, there aren’t a lot of better options for small to medium sized group events. On the whole, though, we’d like to find something more reliable and simpler to operate.
You can learn more or purchase the system at rclapcounter.com.