The next time you catch an Indy Racing League (IRL) telecast,
check out the pits. While the cameras are likely to be following rookie
sensation Danica Patrick, or 2005 Indianapolis 500 winner and likely IRL series
champion Dan Wheldon, it’s behind-the-scenes technology powering these racers’

TechProGuild senior editor John Sheesley and I recently visited
Kentucky Speedway, the one-and-a-half mile long track that hosted the IRL’s
AMBER Alert Portal Indy 300. We roamed garage areas, interviewed technicians, toured
teams’ mobile offices and studied practice and qualifying routines. And that
was just Saturday.

On Sunday I had breakfast with an engineer from the Rahal
Letterman Team, which fields open-wheel race cars for Patrick, Buddy Rice and Vitor
Meira. Then came the race itself with its requisite pageantry, competition and
calculated mayhem.

As soon as the sun appeared, infield and garage areas sprang
to life. Competitors began rolling sleek cars off spotless haulers, tweaking gold-wrapped
motors and transferring equipment of all kinds, shapes and sizes.

Laptops were everywhere. Each team boasts a full complement.
PCs, servers and wireless technologies are used heavily throughout race
weekends by engineers needing to wring the utmost performance from cutting-edge
racecars. Information technology is pressed into duty for a number of tasks.

At the forefront is engineers’ need to make sense of data
reported by electronics systems onboard each racecar. Data acquisition engineers
–also known as DAGs, for data acquisition geek – are responsible for ensuring
the data stream and collecting critical metrics. It’s common, too, to see a
representative from the major motor manufacturers – Chevy, Honda, Toyota – in
each team’s pit. The motor reps also press laptops into service as they monitor
engine performance.

Larger multicar teams also maintain servers, in addition to
gaggles of laptops, in the pits. Back
in the garage area, typically yet another set of servers is housed in team
transport trucks.

Team transports: Not your Cousin Eddie’s RV

John and I spoke with several team engineers, many of whom
assume IT responsibilities in addition to other race-related tasks. A few
invited us in to see their offices firsthand. And that’s what these transports
are: well-equipped offices on wheels. These are no run-of-the mill RVs, but
top-dollar tractor-trailers. They house everything from servers to backup
racecars and serve as nerve centers for each team’s operations. (View the Trackside
Technology Photo Gallery
for images from the track, including photographs
of team transports).

Each hauler sports numerous external ports that can be connected
to landlines and Ethernet cables, which crisscross the infield’s hospitality
and garage areas like spaghetti. The trailers also house “DAGtuaries,”
or the workspaces where each race team’s engineers pour over gigabytes worth of
practice session data.

While plush, space is still at a premium. Transporters must
also house mechanics’ benches, tools, spare motors and more. Picture squeezing
four or five employees, and their workstations into an area a little smaller
than a single typical cube and you have a DAGtuary. It’s in these tight spaces
where some of the most critical race weekend work is performed.

Crunching data

Most IndyCars carry hardware modules from Pi Research. The devices monitor numerous
sensors and track critical metrics, such as engine performance, tire pressures
and chassis behavior. The onboard electronics systems record the sensor information
to a data acquisition box. Following test sessions, the data is dumped to technician’s

All of the data–and the data accumulates quickly with 32
different sensors each tracking numerous metrics every second–is offloaded from
the onboard data acquisition box to engineers’ laptops via Ethernet cable. When
actually racing on track, transmitters in each car send a constant stream of
telemetry back to receivers in each team’s pit. Rahal Letterman Racing, whose
Patrick placed the number 16 Honda machine on the pole, employs UHF

“There’s a receiver radio with a serial stream, basically,
that goes to the laptop,” said Engineer Rob Trinkner, who doubles as the
team’s IT manager. “One reason we
choose to go with the UHF band is because of its penetrating abilities. 802.11
is very directional, in that its 2.4 GHz high frequencies are typically very
directional. [They] are not good at penetrating objects.”

Infield buildings, trucks, and concrete retaining walls, of
course, all present obstructions that interfere with reception. Choosing
dependability over throughput has its disadvantages.

“You get into a bandwidth issue on the telemetry where
you can’t send everything back to the pits at the rate you want to send it,”
said Jim Foley, Assistant Racing Engineer with Rahal Letterman Racing. “So,
there are certain channels you decide I can’t look at–the trace of shock
displacement – real time and make anything out of it. I need to log that and
look at it after the car’s [done] running. But other things, like what gear
position he’s in or what his steering angle is and stuff like that, that’s
stuff we can absorb real time. It’s a bandwidth issue.”

The data teams transmit is so sensitive, and would provide
significant competitive advantages to other teams if revealed, that it’s
encrypted. Next to wing angles, which are carefully concealed beneath covers
almost any time a car isn’t racing, the data returned by onboard systems is the
next best-kept secret.

“It’s like anything,” added Trinkner. “If you
really wanted it, you could probably get it with enough time and enough packets
of data to analyze. But, typically, by the time’s somebody’s decrypted that
data–in the environment we’re in–people are too busy doing other things.”

Figure A

The Pennzoil team monitors telemetry from its racecar during the AMBER
Alert Portal Indy 300.

Thus, in addition to employing and maintaining 802.11 transmissions
for communication between their peer-to-peer workgroups or clients and servers
(larger teams run larger networks; smaller teams run simple workgroups), engineers
must maintain UHF data streams to ensure the vital telemetry is captured, while
also managing digital keys.

Those responsibilities are just the beginning. Trackside
technologists’ most important duties are collecting critical data from the
racecar and quickly making sense of that information. Teams typically receive
only an hour between practice sessions, as well as a short window before
qualifying. Conditions become even more hectic in the heat of a race.

“One of our
biggest challenges is taking an enormous amount of information and boiling it
down,” added Foley. “That’s what’s really, really hard about this
business; to not get absorbed in some squiggly line that isn’t going to tell
you anything in the half-an-hour you have.”

Teams use a variety of tools, including specialized
applications from Pi Research, to determine how well the car’s working.

“But as with everything,” Foley said, “you
get to a point where there’re certain things you want to customize, and to go
through an outside vendor to get that done isn’t necessarily a timely thing. We’ll
use Excel a lot, Visual Basic a lot. We’ll use MATLAB a lot. We’ll write our
own routines and our own macros. And the key to this is when you have an hour
in between sessions and it’s going to take half-an-hour to make any changes you
want to implement. So, now you have half-an-hour to post-process a half-a-gig
worth of data. You can’t be just thumbing through it. You have to be writing
macros that are going to spit out answers.”

Preparation is one way teams attempt to minimize the changes
that need to be made between practice sessions.

“In this business, a lot of what we end up doing is due
to good bookkeeping, as we say,” added Foley. “You’re always
referencing what happened last year. What does the data tell you? If the result
last year was good, which it was for us here last year, then you want to
heavily reference that. But then you have to sift through everything and go ‘OK,
but what is different that I have to compensate for?’ If you just show up with
the same thing you had last year, well then, you’re a year behind.”

Figure B

Danica Patrick consults with her engineers following a practice session.
Ultimately, she got the setup right and earned the pole position for the AMBER
Alert Portal Indy 300.

Trackside IT proves paramount

Just how important did all the data collection and analysis
prove in the AMBER Alert Portal Indy 300 race? Both Patrick, who’s best practice
lap (rain canceled qualifying) made her the first woman ever to earn multiple IndyCar
Series poles, and race winner Scott Sharp credited their engineering teams with
powering their successes.

Figure C

Scott Sharp celebrates his victory in the AMBER Alert Portal Indy 300.

“My engineer, Ray (Leto) came up with a good plan for
this weekend,” said Patrick. “I just went ‘OK.’ He planned it right.”

Scott Sharp, who won after leading the last 60 laps with
Rahal Letterman Racing’s Meira breathing hard on his tail, attributed the win to
his technical team’s contributions.

“I can’t say enough about my engineering staff,”
Sharp said immediately after the race. “We huddled together between
warm-up and the race and made lots of changes. Once you change the car and you
don’t have a chance to practice it again you’re probably going to have to tweak
it a bit. It took us a couple pit stops to get the car right and it just came