Commodore’s Garage #26 – Pre-Build Prep, Post-Season Tests

Believe it or not, the grand event known as Week 13 is upon us yet again and with that comes a new build.  By now, you’ve most likely run your final race of the 12-week season and it’s simply a matter of waiting just over a week until you can race again.  There’s a lot you can do in that time to prepare for the next season, however, and by simply sitting around and letting the time pass you could very easily lose your rhythm from the season.  To keep you in the rhythm of the racing grind during the off-week, here are a few tips and processes you can go through to make sure you’re prepared for whatever is thrown at you with a new build.

Setup Exports

Few know what the “EXPORT” button on the Setup Garage menu does, but it’s absolutely invaluable if you’re in the process of developing a setup and want to take it into the next season, or simply want to record it for reference at a later date.  Clicking this little button will create an HTML file of whatever setup you have loaded at that time, exporting everything about the current setup from springs and shocks all the way to tire data (assuming you’ve just finished a run and have the data available).  The benefits for doing this with your favorite setups are immense, especially since it will export the corner weights, deflections, and all the small details that could get changed a few builds down the road.  This allows you to rebuild a setup from the past to get the details back to where they were without simply guessing.

Outside of season’s end, it’s not a bad idea to export any setup that you find works very well for you (or even your teammates).  A notable example of an older export file that I still look at today is the setup Alex Scribner and Brian Day used in the 2015 NASCAR PEAK Antifreeze Series race at Daytona.  I exported the setup file following the race, and it was referenced earlier this year when the series went to Daytona for the season opener.  Not much of it was directly applicable because the 2014 car was on composite bump stops and the current car is on bump springs, but the weight distribution, alignments, and even ride heights were used as the starting point for this year’s Daytona car.

We also exported the setup Nick Ottinger used at Watkins Glen in 2015 to lead every single lap in the NASCAR PEAK Series race.  The car didn’t change much from 2015 to 2016, and the car that was involved in that thrilling last-lap battle was exactly the same as the year before.  Still, we have the setup details documented for all eternity, which will come in handy later this year when the series returns to road courses on the newly re-worked Gen 6 chassis. Exporting setups will completely eliminate those moments of “that setup was great, but it’s gone forever”, and everyone’s had that moment in sim-racing at some point.

Telemetry “Mule” cars

When the Gen 6 car was in the development pipeline, there was a lot of confusion as to what the new car would be like compared to the departing “COT” Gen 5 car.  To make the transition easier, as well as to help usher along the setup process for the new car, we built a dedicated test car specifically to log the telemetry data to compare it directly with the new car.

The last COT car that we built at GFR, this car (and the setup underneath it) was used to make direct comparisons between the Gen 6 and COT cars to determine how to approach the setup process with the new car.

This is actually simpler than it sounds, and really doesn’t take a whole lot of time to get ready.  Moving from the COT to the Gen 6 car, we already knew that the Gen 6 would do away with the rear sway bars we’d been using for years to replace large right-rear springs.  For the most part, we’d all forgotten how to run a car without a rear sway bar, so the test car was built without one.  Outside of that, the rest of the car was extremely generic, with values we assumed would be easy to replicate on the newer car like equal front springs at 500 lb/in, a 2” sway bar, etc.  Nothing outrageous and definitely nothing like we’d been using for races, but something that could be built quickly following the Gen 6 car’s release.  Once the setup was built, it was then a matter of driving the car a lot and recording the telemetry from the runs.  We looked at how much the car dropped at speed as well as how quickly it raised up as it coasted to a stop (aero checks), how much the car rolled and pitched (mechanical checks), and, probably the most significant thing, how the tires heated up from the setup that was installed.

Once the Gen 6 car was released, it was simply a matter of installing the same setup (as closely as possible) and running the same tests again.  Since the setup was the same on both cars, by directly comparing the data we were able to see how the new car differed from the old car as well as what had gone unchanged between the two.  If you’re not in the mood to build a dedicated car to do all this like we did, you can do the exact same thing by simply recording telemetry during a race and doing the same later on after a build has been released.

TESTING

You’ve just run a full season, and you probably had some ideas on how to make your cars better but may not have put the ideas to use.  The off-season is the perfect time to test, and really test.  Maybe you want to try a stiffer spring package, or a new arrangement of shocks, or who knows what?  Take those ideas and apply them, then jot down what happens.  By the time the season rolls around you will have a laundry list of things that worked and what didn’t work, and those things can be implemented for the next season.

I want to stress that this point that testing is not the same as practice or setup building sessions.  For a practice session, we’re either tailoring a chassis setup to the track and conditions or we’re simply trying to get experience on the track to help lower lap times or to simply become more comfortable.  In a testing session, there is almost no interest in the stopwatch but instead about how ideas, configurations, or specific adjustments affect the car.  We’re looking to understand the car better, and that information will be applied to make the car faster in practice.

In April of 2016, the iRacing Class B series had an extended break in the schedule.  Instead of stabling the cars and ignoring them until the next race, we put together a list of all the things we wanted to try, the things we didn’t understand, and things we wanted to develop further in the time off.  The picture above is the first test we ran on the Class B cars in the sessions from April 28^th to May 5^th, including the details to be tested.

Prior to ever starting, we had a full schedule of what needed to be worked on and how it needed to be approached for the best results.  For this session we went to Charlotte, specifically because of the high loads and relatively smooth track.  The more outside influences we can eliminate (bumps, wind, weather), the more accurate the test results.  As you can see, we started with the setup we used at Texas, but adjusted it slightly to suit Charlotte Motor Speedway.  Once that was done, the car was not adjusted anymore outside the bounds of the tests.  When doing something like this, the idea is to keep the car as constant as possible and only making a single change, thus the line about constant Sway Bar diameter and other settings.  This test involved running all the spring rates available between 300 lb/in and 450 lb/in to see which springs, if any, bound too early to be useful and which ones gave us the best splitter height control.

Which spring was the fastest?  I’m not sure because lap times were not recorded in the test.  Instead, we recorded the ride heights and splitter heights for each spring and compared all the data to find out which springs gave us what we were looking for.  Each test we ran had the same type of process, ignoring lap times an instead looking at what happened as a result from the adjustments.  In the entire 31-page-long “report” (I kid you not), there are only three of the 14 tests that have any reference to the car’s lap times following the adjustments.

Despite being just off of the lead pace in the early part of the 2016 season, the information gathered from the tests went into almost every single car from that point on, with a large amount of the information going straight into Alex Scribner’s car that eventually got developed into the car he raced at Indianapolis a few months later, kicking off a series of wins and, eventually, a series championship.

Do you have to go as crazy as we did and write up a real-world-like schedule?  Not at all!  We simply had so much stuff that we wanted to try to understand that, had we not structured everything, it would have been a disorganized mess with nobody ever on the same page.  Since we had up to four cars in a session at a time, we had to say “This is what we’re doing right now, and this is what should be in the cars.”  There were also some tests that one driver did and the rest did not, usually because the test didn’t apply to everyone’s setup and would have been useless to the other drivers.

Keep on Developing!

The single worst thing you can do with a new season is to say “Well, now none of my setups work” and completely start over from scratch.  This takes months of work and throws it out of the window with no idea where to go in the upcoming season.  Maybe a new build changed your car somehow, but you should focus more on how the build changed the car and adapt from there.  Sim-racing is unique in that everybody has the same car, so if my car gets an update, your car gets an update as well.  What’s really cool is that the update is exactly the same for all of us, so early-season advantages are going to come from whoever understands the car updates the best.  For example, let’s say the new build simply changes where a shock is mounted on the car.  Some simple testing could result in discovering that, if I just increase compression on the shocks by two “clicks” I’m back to what I had last season, I’m already miles ahead of the driver who scrapped his setups and started over.

New updates to cars are inevitable in sim-racing due to advances in modeling, coding, or even updates to the real-world cars.  The key to handling these changes is to not become overwhelmed with all the changes you see, and instead taking the data you have access to and finding out how that data has changed.  There’s no guarantee that a build will change whatever car you drive, but it never hurts to take advantage of the week off and make your cars a little bit better so you can hit the track running once the season begins.
~~~~~~~~~~~~~~~~~~~~

To keep up to date with The Commodore’s Garage, return to Sim Racing News every other Friday afternoon and “Like” our page at https://www.facebook.com/CommodoresGarage

You may also like...

Recommended

Cal State Fullerton’s Logan Clampitt dominates eNASCAR College iRacing Series at Nashville

Recommended

Audio Developer Blog – the Sounds of Rain

Recommended

eNASCAR College iRacing Series Race Preview: Nashville

Recommended

This Week in iRacing: April 16-22, 2024