Developing a Setup

Methodology

File naming system

I find that when I'm developing setups, it's very important to have a system. There are enough different parameters to change that after a while, it's hard to remember what change did what. (This is called "getting lost".)

I have a spiral notebook in which I make notes. If I find something that really works - or something that really doesn't - I'll make a note about it in my notebook.

Also, I save each modification with a new name before I test it. This gives me a development trail that I can look back on. I use names like this:

Ali Eag F2 Sil x2b

The "x2b" means it's an experimental setup, version 2, iteration b. As I make small changes, the suffix will be x2c, x2e, etc. When I find a setup I'm happy with, I sometimes rename it, omitting the "x", to signify that it's no longer experimental. If I come back later, or start again with a big change such as different ramp angle settings, I'll bump up the version, so I'd be starting at x3a and so forth.

Some people use dates; others use lap times. It doesn't really matter what you use, as long as you have a system that makes sense to you, and that you can use to organize your setups so you can keep track of what changes you made and what their effects were.

Working from a baseline

I find that it's extremely useful to work from a baseline setup. The requirements for a given chassis do not change dramatically from track to track, and the same basic setup will work almost everywhere, with the exception of the Nurburgring and the steeply banked ovals.

Therefore, once I find a setup that works for a chassis, I'll use that as a baseline. When I go to another track, I'll copy the baseline setup, adjust the gears to be appropriate for the new track, and work from there.

For the ovals and the Ring, I'll look at my baseline for the chassis I'm working on, and also look at a setup from another chassis that I've got for that track, if I've got one, or a similar track. I'll try to work from a combination of the two.

For example, if I've got an Eagle setup that works at the Ring, and I'm going to run the Ferrari, I'll look at my Silverstone Eagle and Ferrari setups and see how they differ. My Eagle at Silverstone might have, say, a little more roll stiffness at the rear relative to the front, and brake bias to the rear a bit compared to my Ferrari at Silverstone. So for the Ring, I'll put the settings from my Ring setup for the Eagle onto the Ferrari, but I'll make the front a little stiffer, and move the brake bias to the front.

See the Chassis Weights and Dimensions table and the Chassis Characteristics page for more details about the differences and similarities of the various chassis, and the Circuits page for more details about the circuits.

Choosing baseline tracks

I find it's easier to use the same few circuits to develop my baseline setups. That way, I get to know the nuances of these tracks, and when I move to a different chassis, I'm focusing on the differences in that new chassis vs. the one I've been running recently, rather than on the track.

Road and Street Circuits

Originally I used Monza as my baseline road course, because it's relatively level and fairly simple. However, eventually I realized that Monza is something of a special case, because it really has only right-hand corners, so a setup that has asymmetrical camber is pretty much always going to be faster. Also, it has only fairly subtle banking and elevation changes. This isn't bad, but I found it's more useful to work on baseline setups at circuits which have more obvious vertical loadings and unloadings, and which have both right and left-hand corners.

Now I use Silverstone, Zandvoort, and Kyalami as my baseline tracks. Each has particular demands that, together, help me to develop an overall picture of how the chassis behaves and what it likes and doesn't like.

Silverstone is great because it has simple, constant-radius corners but fairly high vertical loadings due to bankings, bumps, and dropoffs at several corner entries. At Silverstone I try to develop a setup that's balanced and doesn't slam down on the bump rubbers anywhere (except over the bump in Maggots). A setup that works well at Silverstone will work fairly well at most road and street circuits with only minor changes in ride heights and brake balance, and maybe a slight change in spring rates and/or anti-roll bars.

Then I take the Silverstone setup to Zandvoort. Zandvoort is a lot bumpier than Silverstone, and has somewhat higher vertical loadings, mainly in Zijn Veld, a fast, banked left-hander that generates a lot of download as it transitions from downhill to uphill. Zandvoort also requires a lot of precision in placing the car. If the car is nervous over bumps, that will show up here. Once I've dialed in a setup for Zandvoort, I have a pretty good idea of what the car wants on a bumpy circuit.

Then I go to Kyalami. Kyalami is smoother than Zandvoort, but it has a lot of crown transitions and has tricky dropoffs into Crowthorn and the Esses. It also has very high vertical loads in the right-hander in the Esses; if the car gets loose under power here, I know the rear suspension is bottoming on the bump rubbers. Usually the Zandvoort setup, with slightly higher ride heights and/or stiffer springs, will work fine here.

Now I've got baseline setups for relatively smooth tracks, bumpy tracks, and high G road and street circuits, and I have a good idea of how that chassis responds to various changes. I can go to the other tracks, start with one of the baselines, and adjust from there as necessary.

See the Circuits page for a discussion about the characteristics of the various circuits.

Ovals

When it comes to ovals, I consider Milwaukee to be just about the perfect race track. It's smooth and shallowly banked. Settings for Milwaukee are not too different from those for a road course, except for asymmetrical camber (positive on the left) and asymmetrical spring and damper settings. I use softer spring rates on the left front to help keep from overheating the right front, and also run a stiffer rear anti-roll bar to also help out the right front tire. I typically back off on the coast side of the diff a little for the same reason, using 45 or 60 instead of 85.

Michigan is an excellent big oval. I like it for working out baseline setups for steeply banked ovals. For Michigan, I'll use settings similar to those for Milwaukee, but with higher spring rates and possibly stiffer dampers to cope with the higher vertical load induced by the banking. The left front spring rate will be very soft, again to help out the right front and keep it cool. I'll also switch to an open differential (85/85, 1 clutch pack) for the same reason.

Once I've figured out setups that work for Milwaukee and Michigan, I can extrapolate to other tracks.

Darlington and Talladega seem to work with a Michigan setup with only minor alterations.

Charlotte and its near-clones, Texas and Atlanta, are even steeper than Michigan, and have tighter corners, so spring rates will need to be even higher.

For tracks with bank angles in between, like Gateway and Fontana, I'll extrapolate between Milwaukee and Michigan. Loudon and Phoenix are special cases because of the high vertical loads induced by the steep descents into the center of the corners, so higher spring rates are needed.

Shallow tracks like Homestead and Pikes Peak will be more like Milwaukee.

Refer to the Oval Track Data for the bank angles at each track.

Lapping

When developing setups, it's very important for the driver to be consistent in driving the car. Consistency and repeatability are more important than outright speed. It's important to be able to compare the effects of changes. Therefore, the driver needs to be able to do the same thing, lap after lap, as nearly the same as possible. This is a skill that the good development driver will need to develop.

Also, when testing, it's important to go back to a known baseline setup periodically and run some laps again, to make sure that any changes in performance made on the setup under development are actually due to changes in the setup, and not due to either an improvement in driver skill due to practice, or a reduction in driver performance due to fatigue.

When I'm developing setups, I do a few warmup laps to get myself into the rhythm of the track, using an existing setup if available or a baseline adapted from another track.

After a short break to allow this to sink in, I'll create a copy of the setup, make a tweak or two and try the new setup. On a typical road course, I'll run five to ten laps, until I feel that I've gotten a pretty good idea of what my limit is with that setup. Then I'll make another change and try that for a few laps.

I'll continue this until I'm satisfied. If I feel I'm getting lost, not sure if I'm making improvements or not, I'll go back to my original setup and do a few laps with it to see how it feels compared to my latest, and to see what kind of times I can do with it now that I'm personally dialed in to the circuit.

For future reference, I'll export my lap times to a file, and I may also make notes in my spiral-bound notebook. These days, with GPL Race Engineer's notes feature and GPL Replay Analyser's replay analysis capabilities, I tend to save replays as a record of my development, and put many of my notes right in my setups.

Setup development takes a lot of patience, and it can be tedious. But the end result can be enormously gratifying, especially if you wind up with a setup that is faster, easier to drive, or both.

Performance Analysis Tools

These days real-world race engineers on well-funded teams have access to telemetry and other forms of electronic data acquisition to help them analyse the performance of the car, the engine, and the driver. Data collected on the track is run through computer programs and displayed in more or less user-friendly form to the teams. This can help them determine the effectiveness of setup changes as well as other factors such as new suspension and aerodynamic components, etc.

GPL provides some basic tools, including lap times and tire temperatures (on the Setup screen), which can be exported to HTML files. Replays can also be saved to disk, and viewed later. (See my Hardware FAQ for information about how to save many laps of replay even if you have only 64 mb of memory.)

The GPL replay file contains a great deal of information about the car's behavior. GPL Replay Analyser is an extremely well-designed utility which can extract and process information from replays files and display this information in very useful ways.

Another utility, GPL Spy Girl, can combine laps from different replays so that the cars can be viewed as they simultaneously travel around the track.

See Utilities for more information about GPL Replay Analyser and GPL Spy Girl.

Second Computer

GPL Replay Analyser and GRE are much more convenient to use if you have a second computer which you can connect to your racing computer via a LAN (these days this is a very inexpensive solution). You can share your replay and setup folders so that you can access them across the LAN from the second computer.

This will allow you to use GPL Replay Analyser to review replays you've saved without even leaving GPL. You can als make changes to the setup using GRE, again without leaving GPL. This can be a very big time-saver and makes setup development even more fun.