Mini Racecar Tuning #1

 

Although BHS started doing the tuning in the shop, I ended up having to pretty much start from scratch & learn how to do it myself. FYI here are three great books I've found:

        How to Tune and Modify Engine Management Systems
                
by Jeff Hartman, Motorbooks Workshop.

       Dyno Testing and Tuning 
                 
by Harold Bettes, SA Design

       Engine Management Advanced Tuning 
              
by Greg Banish, SA Design

One of my key goals is to avoid some of the issues that have hit other highly customized Minis. In my opinion, a big challenge with tuning these engines comes from the inherent difficulty in tuning a small forced air engine for all the extreme environmental variations (summer/winter hot/cold dry/humid, altitude variations, etc.) - especially if you're trying to do it all in a single tuning session. What complicates this even more are the small but significant differences between running the car on a dyno vs. on the road/track.

So my approach has been twofold: 1) capture as much real-time, real-world information as possible (including weather conditions) , and 2) develop techniques for using this data to quickly and precisely adjust the tuning maps to match the real-world conditions.

To achieve this the engine has a large number of sensors installed. Three of the most important are the wideband Lambda, EGT, and knock sensor. The Lambda is the most important way to check the fuel maps. And the EGT and knock sensors are critical for adjusting the timing, as well as providing key indicators for other potential issues.

Getting the Lambda & EGT working was easy with off-the-shelf parts, but no such luck with the knock sensor. It requires a bandpass amplifier tuned to match the specific engine configuration. I'm working on designing my own DAC-based circuit for this, but in the mean time I found an aftermarket box that seems to be working well. It appears as the small circuit board at the bottom of the wires below (fyi the wiring in this picture looks worse than it does in real life...and I'm working on simplifying it)

IMG_02403.jpg

Here is an example of the kind of log data I get out of a run:

graph1.jpg

Since the main tuning map is a function of RPM and MAP, I created two graphs corresponding to the instantaneous values of these sensors at each RPM/MAP point. The value at each point is represented by a color-coded dot. The color coding is structured to make problem areas visibly stand out. These graphs are automatically generated from the logged sensor data. So after each run I can immediately see where the maps need to be adjusted. The following picture shows Lambda as a function of RPM/Boost, and EGT as a function of RPM/Boost. RPM is the X axis & boost is the Y axis:

Old_Lambda_Graphs.jpg

Over the next couple of months I took the car to a couple of one-day track sessions to do additional tuning & adjustments, as well as making sure everything is running reliably before I take it to a multi-day event.

One of the features the MoteC supports is boost control using a solenoid connected to the pressure line going to the wastegate. The wiring for the solenoid was not quite right, but I finally fixed it. So the next step was to set up the parameters for the control algorithm.

The first step in that process is to find the "target" duty cycle. This is done by setting a fixed duty cycle. I didn't want to accidentally make the boost too high, so I set a 35% duty cycle to begin with. This increased the maximum boost by about 5psi. to about 20psi. (see plots below). I then had to make some adjustments to the timing & fuel tables at those boost levels.

Old Plot:

Old_Lambda_Graphs (1).jpg

New Plot:

New_Lambda_Maps.jpg

Because I just used a fixed duty cycle, the graph is shifted to the right. Once I set up the PID controller properly, I should be able to get it to boost at least along the blue line drawn into the graph below. This graph shows the new data overlayed on the old data (in black):

Lambda_Diff_Target.jpg

I did have an issue on the second run session where the engine cut out briefly. I traced it to some water that was shorting out the sync signal. When I cleaned the contact & reassembled it, the problem didn't occur again.

Also, this is also the first run I've had a chance to log GPS data from the AIM data logger. This software is very different from the analysis software I've used before, so I'm still getting used to it.

Just for fun I tried out the engine performance analysis view. By entering the vehicle weight (including driver), frontal area & drag coefficient, it calculates HP & TQ to the ground.

Analysis_Screen.jpg

In theory this says I'm making 315 HP & 277 ft/lb of torque to the ground...BUT I'm very doubtful of those numbers at this stage. I'm planning on taking the car to the dyno in the near future; that'll give me something to compare this to.

Additional Tuning Tools

I mentioned previously I was playing with using external applications to take logged engine & environmental data to adjust the various tuning parameters on the Motec. To play with this idea I made an Excel spreadsheet that combines the logged data with any of the tuning parameters I want and applies a transformation/correction. To begin with I'm testing the idea using the fuel table.

The first tab of the spreadsheet is a dump from the logging output of the Motec. The second data tab is the log from the bluetooth weatherstation I'm using to continuously grab environment data during the day:

Engine_Log_Data.jpg
Weather_Log.jpg

The next tab has the input tuning parameters - in this case the original fuel table used during the run:

Original_Fuel_Table.jpg

I then apply a filter to the log data. In this case I'm removing all deceleration data (the lambdas in those areas will skew the analysis):

Filtered_Data.jpg

The next tab is a pivot table summarizing the measured lambda values at each RPM and MAP point. Since not all RPM/MAP combinations were measured, there are a number of holes in this table (it fills in at the higher RPMs):

Lambda_Table.jpg

The next tab is the correction table. For cells with a measured value, this has the actual correction factor to apply to achieve the desired lambda value. For cells that don't have measured data, the value is interpolated from nearby data. In some cases I override certain cells where I don't think the masurements were accurate, or to help smooth out between the sample points:

Correction_Table.jpg

All of this results in the output tuning table. In this case you can see some interesting additional hills & valleys added to the fuel table:

New_Fuel_Table.jpg

This data is then re-uploaded to the Motec. If necessary this cycle can be repeated multiple times to optimize the solution

After the fuel table there's timing, short-term corrections, long-term corrections, etc. etc. With some variation the same approach can be applied to all of them

Pretty cool, eh?

 

Posted on November 20, 2013 and filed under Cars.